So i’ve been trying out the new functionality a little and there is something I don’t unterstand and wanted to check with you before filing a bug. So heres the setup:
1 untrusted cloud machine and several syncing machines
Connecting up the first machine to the untrusted cloud works fine
when I try to use the second machine to decode the encrypted folder it will sync but instead will download the encrypted data (8.syncthing-enc …) instead of decoding.
It seems to work if I also sync the folder to another trusted machine in parallel.
Am I missing something here? Some configuration option I missed?
so now, after pausing and restarting I get “up to date” on the second machine but still with the encrypted folders instead of the data itself. The other side (the formerly working client) now is disconnected and reports closed: handling index-update for ewn3m-hsfv3: siv: authentication failed
The setup on your second “client” machine should be identical to the first - in terms of password, etc. That you’re getting the the encrypted data indicates you did not set the encryption password.
The thing is even if you don’t set the password on a send-receive folder connected to an untrusted/encrypted folder, you shouldn’t get encrypted data. The connection should drop and you should get a warning saying something like “the other device sends encrypted data, but you didn’t set a password - fix that”.
The only way I can see that you are receiving encrypted data is if either the folder is set up as receive-encrypted or the folder on the untrusted device isn’t actually set up as receive encrypted anymore. Or there’s a bug.
To better understand what’s going on, can we please use A for the first trusted device, U for the untrusted device and B for the second untrusted device.
The latest authentication failed message is happening on device A, and the affected connection is to U, right?
That is also a pointer to the thing I wrote about above: Either U is sending indexes with a different password (shouldn’t happen unless the folder was reset - once a password is set it shouldn’t ever change) or it is sending unencrypted data (that should however cause a connection drop).
Basically even if you did something differently than intended by design (no accusation or anything that you did) what you see shouldn’t happen.
It looks like somehow the device U and B were able to establish a “trusted” relationsship, thus B got encrypted files from U considering them as unencrypted. Those then went back to U, which then sent them on to A which rightfully fails when seeing them (not correctly encrypted).
Can you please store and share all logs from the process, mainly from U and B.
ok. Now I don’t understand anything anymore:
To provide you with logs, I did reset everything and added a new test folder on A to sync to U.
U is set to untrusted at A, so anything else than recieve encrypted on U should not be possible. When I sync the folder first, nothing happens but both A and U will tell me “up to date” (while on U it is empty). When I now pause the Folder on A and then resume it does sync however it stores it on U unencrpyted, while still telling me “receive encrypted” in the GUI.
I can only say that I had the same problem a few days ago. Even though I thought that I had set up everything correctly, I got encrypted data mixed with the actual files on one device. I was using v1.14.0 though, so I decided not to report the issue until I test the same configuration with the current RC.
Something is going wrong badly here - I’d like to know what and fix it. I played around with doing similar things (adding folders and adding no/incorrect passwords) and it worked as expected for me. Which isn’t to say there’s no problem, I obviously do things the way I want things done, just that I need your help.
Ideally there’s a clean reproducer, i.e. you can give a list of steps I can follow to encounter the bug myself. If that’s not possible, please post logs. With a test setup there shouldn’t be anything sensitive except maybe IPs, if you consider them sensitive, and “half-sensitive” device IDs (leave just the first block). Redact them if necessary. Then attach the log here in this thread please.
There’s no significant change between v1.14.0 and v1.15.0-rc.1. There have been a few fixes since, but they are not related to anything we are talking here. So likely what you saw is relevant to this issue. You should still upgrade to the latest rc when testing encrypted folders, if only to make sure we are talking about exactly the same thing and line-numbers in logs match.
All Devices on v1.15.0-rc.5, Windows machines using SyncTrayzor
Devices A and B are connected to U. Status: Connected (unused)
Steps to reproduce
Add new Folder to Device A and share it with encryption password
Receive Folder on U and add it.
=> U will now show “Up to date” but will not receive any data. A will show “Syncing” for the device and “up to date” for the folder while not sending any data.
Pause the new Folder on A and resume it
=> A and U will now sync but U will now have the unencrypted data at the chosen path.
I repro-ed with the steps above. Looking into it right now - won’t need any logs.
This is a biggish issue unfortunately: The encryption connection handling was created when we still dropped a connection whenever the configuration changed, and relies on that. Now we don’t drop it anymore, and the connection doesn’t get to know about the encryption until it is dropped for another reason (restart, device pause, …).
