private and open shares with same peer?

Support
1

From the docs, I assume answer is No, but asking in case I missed something:

Can I have both Encrypted (untrusted) and Open (trusted) Directories with the same peer?

Right now I’m using Untrusted (Encrypted) Devices — Syncthing documentation with a file watcher on the directory to “open” the files… something similar to Share files from encrypted peers but just copying the files locally.

2

From a security/privacy perspective it’d be unusual, but since the encrypted/untrusted setting is about the storage format the data in a Syncthing folder should be in before sending to a peer, a pair of Syncthing folders both pointing at the same filesystem path can be configured as trusted for one and untrusted for the other.

Then on the receiving peer, there would also be a pair of Syncthing folders, but each pointing to separate filesystem paths. One directory would contain plaintext while the other “untrusted” one contains ciphertext.

3

a pair of Syncthing folders both pointing at the same filesystem path can be configured as trusted for one and untrusted for the other.

Not sure how to do that. My .local/state/syncthing/config.xml file have <untrusted>false/true</untrusted> under the device, not the folder. I was assuming something less obvious that escaped me in the documentation, like leaving the password empty (tried that already).

4

The untrusted option for a device is just a failsafe to make sure Syncthing will refuse to share any folder to it without encryption.

Untick that. Then enter a password for folders you want encrypted on the other end, where they will be added as type receive-encrypted. Leave the password field blank for folders where you want plain data on the other end, where they will be added normally as type send-receive or whatever you need.

2 Likes
5

oh! the peer option is only used for UI?

Then, what ultimately decides if my peer will send encrypted data is the presence of the password on that share’s peer sharing option, and nothing else?

1 Like
6

Yes

7

To be pedantic, it is actually used in the backend as well, to throw an error if a device is untrusted but has shares without a password. But in essence, yes it is only to guard the user from misconfiguration.

8

Thanks again.

Not sure how to mark as solved here, but it is!

I ended up just going with a well known shared “password” for the public folder. And if i ever need to open it on the shared server I can use:

$ syncthing decrypt --to /tmp/syncthing_public --password hunter1 ~/Sync/Public

easier “steps” than to tell users to edit xml :slight_smile: