I have syncthing running for a sync’ed folder on 3 devices, 2 on-site and 1 offsite.
With trusted device/locations, syncthing works well if the 2 onsite devices burn/die/crash/get-stolen, etc. I can easily recover the data from the off-site device using the same folder id, it rebuilds fine.
However, if the off-site device is un-trusted and I use encryption for it, is it possible to recover the data with a new local install of Syncthing using the same folder id and the encrypted password/phassphrase? Will syncthing auto-recover the same files back to the new trusted device in the same way if not even using encryption?
Worked as expected, except why does it give you an option on the untrusted device to select the folder type?
It defaults correctly to “Receive Encrypted” - however
If someone selects eg “Send & Receive” on the untrusted device, won’t this cause data conflicts? Won’t sending and Receiving encrypted names/data will put junk on the other devices?
For “Receive Only”, will that receive un-encrypted data even though the source device has this target device marked as untrusted? What about conflicts with other devices that are trusted and class this device as untrusted and trusted?
Also for “Send Only”, why is this option selectable on an untrusted device folder that has encrypted data? Will it send the locally encrypted names/data to other devices? I was under the impression, if the folder it shared it relays data anyhow, even if it does not send locally changed data.
Sorry for the 101 questions, but just need some context around the untrusted device folder type options since I won’t be the one who configures the untrusted device(s) and I don’t want data pollution on the cluster.
Incorrect config will cause connection errors, i.e. it doesn’t ever come to the point where your questions become relevant. So also no chance of that misconfiguration on a remote to “pollute” your data.
The reason for allowing the choice: Syncthing can’t know who did the mistake. It might also have been the remote setting a password, and you actually need the plain data locally. And in the end the user has full control of their local config, i.e. restrictions in the web UI are just obfuscation.
So no Poka-yoke. There would be no opportunity to make any ‘mistakes’ if only “Receive Encryption” was fixed/set for the folder (ie grey’d out other options) for untrusted devices. Only the trusted device has a say on access to the encrypted folders/data, untrusted devices don’t - why bother encrypting otherwise.
Not entirely sure what you are saying/asking, however the trusted device encrypts data before sending it to an untrusted one, so the untrusted device gets encrypted data regardless of what it sets as folder-type. It will just cause error messages if it doesn’t set the correct folder type.
Not sure why the “Folder State” is not enforceable in Syncthing, since Syncthing “folder states” can be progreammed to simply block all other drop-down options and prevent Syncthing from doing anything but receiving data like it does anyhow (except now with encrypted data). Whatever-else goes on within that folder outside of Synxthing is treated just like any other normal (non-enytpted) “Recieve only” folder ( eg it has nothing to do with Syncthing - if files are deleted, then they get re-put there as part of a normal receive only sync - if files get added, synching ignores them since its reieve only, etc…etc.)
Based on the current dsign, there may be conflicts of other devices (Device C, D, E, etc.) are classed as “trusted” and Device B is not set as Untrusted on them since passwords cannot pass between trusted devices…but that’s another topic, since what I’m suggesting doesn’t change that existing issue.
@imsodin All i’m saying is on the untrusted device lock the “Folder Type” as “Receive Encrypted” without possibility of changing it when adding the folder.
The untrusted device can still choose a different folder type and provide a password, and everything would mostly work, hence locking down types makes very little sense.
Is that your opinion or do you have any evidence to backup that claim? Your conclusion is based on a false premise that “everything would mostly work”.
Setting any other folder type (other than “Receive Encrypted”) prevents any other use for that folder anyhow (eg you can’t set it on an untrusted device as ‘Send’, ‘Receive’ or ‘Send & receive’ since you can only use that folder as “Receive Encypted” once a password is set on the other device. - the originating device gives a failure otherwise.
Unless encrypted data is stored in a special folder and “Receive Encrypted” removed as a status option altogether (ie making encrypted transparent and independent of folder status), making it so that any device can untrust any other device and still have the encrypted data stored on the untrusted device regardless of folder status on the untrusted device…but thats not how it appears to have been designed?
At the moment, the only way to use the untrusted device folder is to select “Receive Encrypted” Once selected, it becomes a dedicated encrpted folder - no local changes allowed - as per this:
Every other Folder Type option for the folder on an untrusted device is pointless - eg it is either an encrypted folder or not. This is as per current design.
However, if a folder is to be used as suggested (ie still usable locally), then remove the “Receive Encrypted” status altogether, and have encrypted data in a special folder (it’s un-usable by the untrusted device anyhow) to allow normal use of the same folder locally (as with any other folder) using the normal 3xfolder statuses. The current design for folder management would need to change for this to work properly. Otherwise you have a pandora’s box.
All the untrusted flag does is makes sure that all data sent to the remote device is encrypted.
Whether the remote side has the password to decrypt it and what folder type it uses, is none of it’s business.
It would still accept data from the remote untrusted device, given it’s encrypted correctly, which means the untrusted device is fine to use Send & Receive if it wants to and has the password.
The sending device wont send data to an untrusted device that has anything other than "Receive Encrypted’ on it. So its pointless having any other status available. If a normal folder is required, then one can just setup a normal folder BAU. Once set as "Receive Encrypted’ that folder can only be used for encrypted storage anyhow - there is no local use.
I’m not referring to ‘how’ encryption is currently designed, I am aware the originating device encrypts data to an external device and what the untrusted device does.
What I’m suggesting is if the current design remains, then when accepting a folder on an untrusted device, having other ‘folder status’ are completely useless - only “Receive Encrypted” is required.
So your saying the receiving (untrusted) device no longer is untrusted when you enter the same password as the sending device? Why bother having it encrypted then for that device in the first place?
I was referring to this (from the sending device, which classes the receiving device as “Untrusted” for the specified folder, and the receiving device set to “Send & Receive” but without a password) - eg encrypting the data on the sender, so the receiver stores encytpted data.
Sender Device (has password for receiving device for the folder):
so your saying the other folder options are when a password is provided (to ‘decypted’ the data) so the receiving device can BAU as per normal…like I said, why bother with encryption then…looped waste of time.
I would personally set a device as “untrusted” for one reason, which would be to make 100% sure that I will never accidentally share a non-encrypted folder with it. Basically, to have Syncthing protect me from my own potential mistakes.
Normally, that device would not be supposed to ever know the password, but the situation may change in the future, so Syncthing gives us an option to still input the password there and have access to the folder in its decrypted form.
I believe syncthing does not convert folders, instead one has to remove and re-share with different settings (eg with folder type change, since its locked to “Receive Encrypton” once added). So may as well just remove the password from the sending device and make the receiving device trusted again…bau.
if in future syncthing converts existing shares that would be great - however one can just remove the password from the sending device to make the receiving device trusted again (same as providing the same pass on the receiving deivce, except less cumbersome on cpu to encrypted - decrypt, etc.).
because people might feel safer that the data is double encrypted in transit (even if it already is via TLS), or because they changed their mind, or maybe because it’s easier not to screw up when everything is encrypted, and only decrypted where you are sure you want it decrypted. People are weird and they find weird reasons to do things.
@AudriusButkevicius existing transport protocol encryption is suitable enough, syncthing is not an encrption package. If ‘some’ people really need double encryption, then they can use alternative means for serious use (eg boxcrypt, veracypt, etc…)…otherwise its just a gimmick and do syncthing devs want to keep up with the likes of veracrypt, etc. and new encryption methods when quatum computers are made available? just to cater for a few extra secure users who should be using 3rd part maintained packages instead? *
In its current form, once a device folder is ‘untrusted’ to ensure 100% that no mistakes are made, the reiceiving device should only have ‘receive encrypted’ when adding it.
Edit: * for concerns about interception and decryption on transport not on the receiving device, since current method of providing a password on the receiving device will decrypt the data - which is the same as not setting one up in the first place, except for the transport component.
