The functionality to have untrusted (encrypted) devices is available for testing in nightly builds. It is hidden behind feature flag and meant for early testing: Meaning there’s likely a few rough edges and maybe even critical bugs. We do not recommend using it with your
production data quite yet.
To show controls for untrusted devices in the web UI, you need to add untrusted to the config value options.featureFlags - either through Actions > Advanced in the web UI or by adding a <featureFlag> tag in the config.
If you have any questions or encounter behaviour, where your not entirely sure if it’s a bug or how/why it happens, please respond to this topic.
I can’t reproduce - both adding and accepting a new device with the untrusted feature flag set works fine here. And that error $scope is not defined is super weird. I have no clue what might be causing this.
Thank you Simon. I would have liked to help more but when I follow the Editing instructions at the bottom of your link I can’t find the stated edit (pen) icon and the Edit file menu item is grayed out. So I left a comment for a typo you forgot.
No worries, you are helping
Another thing you can try if you want, is when you comment like you just did, you can click on the button next to the mouse in the screenshot below. Then you can edit the text to fix whatever is wrong with it (in the screenshot I uselessly changed “this” to “that”) and then comment.
Is it possible for T1 to still directly communicate with T2?
Assuming so, would I do this by sharing the same encrypted folder share between the two and entering passwords for decryption? (or is that only needed between T<1/2> and U1?)
Or, to save overhead, would it be possible to do a trusted (no pass) share between T1 and T2, and Syncthing will be able to merge changes within the same sync location between the decrypted changes from U1 as well as unencrypted changes from the other T?
TLDR: in the above graphic, for a full-mesh sync that uses the cloud node as a buffer, can I mix-and-match encrypted and unencrypted for the same sync target amongst every node on the mesh?
All that said; I can’t wait to start testing this out tonight, and look forward to contributing feedback and scrubbing the docs! You’re all just the best
Yes. You just share the folder between the two trusted devices as you’d always do. You don’t need to set a password (you could, but it’s needless overhead).
With pleasure - but just to be clear, that’s not my work - it’s mainly @calmh’s with some of mine on top, moved along by @AudriusButkevicius and others inputs/reviews and based on a huge preexisting body of work
Got it, thanks! I wasn’t sure if I would be confusing Syncthing on an endpoint by pulling one encrypted feed (with password entered) and one standard/unencrypted feed, with the same folder for the sync target, for a full-mesh sync setup. Awesome!
Unless something is buggy, Syncthing should be doing great or throwing errors that are hopefully clear about what is confusing it (e.g. passwords don’t match).
This opens up all sorts of new avenues and uses for an already brilliant piece of software.
I was toying with a subscription to Tresorit, as they’re doing a special offer for black Friday. I’d much rather donate the money to the Syncthing project.
Can I ask a question? I backup my machines with rsync. Assuming I have the device passwords, will I be able to restore a node with untrusted data on a new PC and use that to get my unencrypted files back?
Anecdotally of course, I used to pay for Tresorit for my entire business. They are semi-abandonware, and I suffered dataloss twice with no help from CS (just generic email replies after 1~2 days with links to documentation). Also axiomatically untrustworthy (closed source + sensitive files = megaYikes).
Uh, I guess I’m saying I agree with you!
From my experience so far, absolutely. I’m even now using Syncthing to migrate my NLE-prod (video edit bay) shares of ~8TB between workstations when I provision. With a 10 GbE NIC, it’s simple and fast. Restores/duplicates using read-only adds are exactly what you’re looking for, and my experience so far tonight shows that the encryption workflow would be just as effective for this. Restores can now be from untrusted repositories.
So yeah, the Syncthing community is a freaking treasure and yes you can do that. Just make sure to keep a non-synced backup of the backup (even with read-only/pull shares) IAW 3-2-1.
If I understand correctly, you want to decrypt data from a device, that is/was untrusted in Syncthing, right?
Then yes you can recover it knowing the password. For now you’d have to create an untrusted folder pointing at the recovered, encrypted data and sync that to a trusted device. There is a standalone utility to directly decrypt data in the making (more or less done, somewhere in review, but not currently active).
When a device is set Untrusted, sharing any Folder with them “requires” a passphrase as stated in the doc. This is OK (Save button disabled in Folder’s Edit/Folders tab as long as no pw is set for them), but when I add the Folder from within the Device’s Edit/Folders tab the check is not performed.
Also, I’d like to see why the Save button is greyed, e.g. using a red font for “If untrusted, enter encryption password” text in fields for which the device didn’t successfully passed the test… better or plus, “You set it Untrusted. Use a password”. There may be a challenge coding this for Device tab at the moment of Device creation. I beg you’ll find, it seems the same you met some years ago when you reached to workaround create a new Folder paused by allowing ignores settings on folder creation.
Thanks guys, ST keeps being my favorite software project
Another wish: it would be great, when a peer that is intended to be receiveEncrypted receives a membership notification, that he was warned to switch to Advanced tab to set himself “Receive Encrypted” before “Save” as we won’t give him the password.
Yet another wish, sorry dev guys you moved ST up a gear
I understand for ReceiveEncrypted side that ignores can’t work as usual, paths/filenames being ciphered too. Would it be possible to have match patterns based on file size ( (?lt) (?gt) ) ? This could also apply to the 3 other folder types.
No. We’re not going to have random-metadata-based ignores (there are topics here discussing that) nor, I think, ignores at all on the receive-encrypted side.
Random ? I don’t understand why you say file size is random. In my mind it is not more random than file names. Don’t worry, I’ll rely on trusted sides responsibility to deal with global folder size. I guess the idea of Folder’s Quota falls under the same no go ? My idea was to offer some GBytes in my storage to family/friend for them to store some amount (let’s say 16GB each to make better than gogool) of encrypted data, keeping myself control on the size.
