It’s not directly related to the new untrusted/encrypted devices feature. I’d really like to keep the focus here on making sure the existing functionality works and is usable, and make changes towards improving those two things. Not adding new more or less related features. So please do discuss such things in a different topic (e.g. folder quota as far as I know hasn’t been discussed yet, metadata-based ignores has been discussed several times before, so please go through that first and base any renewed discussion on new arguments not brought up then). And please keep reporting issues like you brought up above about sharing/pw UI and possibility to auto-select receive-encrypted when accepting a shared folders - those are super helpful and I’ll look into them 
Hi Simon. I don’t know if it’s related to the Untrusted feature development, but here on 1.12-rc3 I meet very frequent (~minutely) disconnections between devices in test. Connections to others v1.11.1 remain stable.
What’s the cause for the disconnects, according to either side logs?
The log is here : https://github.com/syncthing/syncthing/issues/7137
length: read tcp 192.168.22.30:23000->192.168.22.29:22290: wsarecv: An existing connection may have been closed by remote host. (translated)
One device now sees the other stable after changing own setting from tcp://23000 to dynamic+https://relays.syncthing.net/endpoint, tcp://23000 but the other still suffers disconnections (setting is dynamic+https://relays.syncthing.net/endpoint, tcp://:22290):
192.168.22.29:22290-192.168.22.30:23000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 closed: receiver error: illegal base32 data at input byte 1
The log entries quoted here are not mentioned in that issue. It looks related to encryption though, so might warrant an issue of its own with more log context on both sides.
I deleted the folder at untrusted side and the connections drops stopped. At the same time, the issue described in the filled bug disappeared. Disconnections seem to be related to the described issue. Easy to reproduce : just add a file at untrusted side, and wait for detection. Eventually deleted it.
Yes Jakob, these are the log at untrusted. Above is a piece from trusted.
The first paragraph was a simple fix. For the second the field without a PW was already marked as “invalid”, which gives it a red frame. Now I also changed the text in it similar to how you proposed - didn’t require any weird workarounds: https://github.com/syncthing/syncthing/pull/7148
I would like to test the encryption, but I am unable to get the GUI to change.
I have set all devices to “Untrusted” like this:
<device id="" name="" compression="metadata" introducer="false" skipIntroductionRemovals="false" introducedBy="">
<address>dynamic</address>
<paused>false</paused>
<autoAcceptFolders>false</autoAcceptFolders>
<maxSendKbps>0</maxSendKbps>
<maxRecvKbps>0</maxRecvKbps>
<maxRequestKiB>0</maxRequestKiB>
<untrusted>true</untrusted>
<remoteGUIPort>0</remoteGUIPort>
</device>
but the GUI is not changing.
Am I doing something wrong? Previously, I did get the GUI to work no problem when I compiled directly from the encryption branch, but now, after everything has been merged into the main branch, I cannot make it work again. I have tested two different browsers, but to no avail.
I am testing with the current main (ab53687).
Edit 1: Never mind. I missed the necessity to add the feature flag 
. I got confused by the “Untrusted” option available in the config for each device.
Edit 2: By the way, the GUI seems to work fine in IE11 under Windows 7, for what it is worth 
.
I am getting these errors when trying to accept a new encrypted folder.
Failure checking encryption consistency with device XXXX for folder "test1" (zh3on-qqt9y): folder is configured to be encrypted but not announced thus
Connection to XXXXX at 192.168.56.1:13624-192.168.56.1:13620/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256 closed: closed by remote: receiving cluster config: folder is configured to be encrypted but not announced thus
What I am doing is:
- Add the
untrustedflag to both Device A and Device B. - Create and share a new folder encrypted with password from A to B.
- Accept the folder on B.
Then the connection between A and B drops completely and does not seem to reconnect until I remove the newly shared folder.
On the untrusted side when accepting or creating the folder, you need to set its folder type to “receive-encrypted”.
There’s two things to potential improve here: Better error messages and some way to convey the information to the gui that the to-be-added folder should be receive-encrypted.
Ah, I see. Now it is working 
.
Maybe the other folder types should simply be unavailable (i.e. greyed out) when accepting an encrypted folder?
Why does the entire connection between the two devices drop though? Is this expected?
More error messages, this time after trying to manually change the folder type in the advanced configuration. It does not seem to work though. Only by completely removing and re-adding the folder as “Receive Encrypted” I can get the two devices to connect.
2020-11-28 01:08:15 Connection to XXXXX at 192.168.56.1:13620-192.168.56.1:13624/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 closed: receiving index: illegal base32 data at input byte 1
2020-11-28 01:08:15 Exiting indexSender for rn5bb-vz5is to XXXXX at 192.168.56.1:13620-192.168.56.1:13624/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256: service should not be restarted
There’s no information about whether a new folder is encrypted or not available in the GUI right now. That’s one of the two things to improve potentially (maybe not that easy to do) mentioned above.
Yes, that’s expected: If a device notices a wrongly (un-)encrypted connection it drops that connection.
You are on the RC, right? That’s a bug fixed on main. At this point if you want to test encryption/untrusted, you’ll have to use nightly releases.
I have mentioned this above but it probably got lost in my long posts, but I compiled from main (ab53687) today and have been testing using only that, so I should have all the encryption-related commits.
Hmm, but this seems to persist even after removing the folder from B… Only after removing the folder from A too and recreating it from scratch I seem to be able to get the two devices to connect again.
Yeah missed, then you should be good indeed.
I don’t quite get anymore what exactly you are doing now and which error you see (there have been two: the encryption config one and the base32 one). Could you recap the current situation again please.
Yeah, I am sorry for the confusion.
Let us start again from scratch.
- Enable the “Untrusted” flag on Device A and Device B.
- Share a folder encrypted with password from A to B.
- Accept the folder on B, but not as “Receive Encrypted”.
- Connection dropped and
closed: receiving cluster config: folder is configured to be encrypted but not announced thusin the logs. - Manually change the folder type on B to “Receive Encrypted”.
- Both devices reconnect and are “Up to Date”.
However, this suggests that everything works as expected. I am unsure now how I managed to get the base32 error… as I was using exactly the same Syncthing version then. Now there are no errors.
I will report back once I find the culprit.
I have found a different problem. 9d1ee2f seems to be missing from the encryption GUI. This means that the “Ignore” button for new folders does not work in certain circumstances.
You aren’t suposed to change folder type from/to receive-encrypted. It’s possible that when before you already had scanned items while not being receive-encrypted, that after changing that those items were still around, causing this error.
That’s a noop change, just renameing id to device.
Some things may need to be greyed/disabled on untrusted side : ignores as this makes no sense (real file names being unknown), and some (if not all) styles of versioning (maybe simple trash can could perhaps be kept for restore purpose ?).
Keep zen devs, this is just cosmetic as long as Untrusted isn’t pushed in the wild, allow yourself to postpone.
Yeah this is why we do the testing, there’s a lot of things to tweak before general availability. 