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