Early Testing for Untrusted (Encrypted) Devices

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 see what it is about and how it works, check out the docs preview of the user documentation.
For infos on how it’s implemented, there’s the implementation docs preview.
The documentation PR is open, feedback welcome: https://github.com/syncthing/docs/pull/480

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’ve created a test v1.12.0-rc.2 instance with the feature flag “untrusted” set. I’m unable to add a new device through the Web UI.

I’ve hit CTRL+F5 to reload the UI and retried, now getting this:

Cache clearing or using private browsing did not help here.

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.

1 Like

ok, I think I should try another browser and then report back.

1 Like

@cosas Thanks, fixed! If you have a github account, commenting or suggesting a correction in the PR directly on the line with the typo would be more convenient (Draft docs for untrusted devices by calmh · Pull Request #480 · syncthing/docs · GitHub), but obviously I’ll also gladly take corrections here :wink:

1 Like

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.

1 Like

No worries, you are helping :wink:
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.

This is fantastic news!! Thanks so much, imsodin. :slight_smile:

I’ve a procedural question for when I set up my first round of testing this evening:

In the following graphic, let’s say that T1 and T2 often spend time on the same LAN, and that U1 is an untrusted cloud server:

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 :heart_decoration:

Edit: clarified my TLDR

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 :wink:

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!

Oh, and thanks for clarifying the team effort.

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. :smiley:

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. :slight_smile:

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).

12rc3 here

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 :heart_eyes:


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 :slight_smile:

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.

1 Like

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.

@cosas: It might be probably easier to share the folder a second time at the (unencrypted) source side and apply the ignores there?!

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.