Issues when ommiting password when syncing to untrusted device

[sacnoth]

I have a problem when accidentally omitting the encryption password when sharing to an untrusted device. This is a continuation of my reply here:

Should not Untrusted status be introduced?

I think it’s not just a problem with introducers sharing U to B, but when sharing folders in general. I was testing the untrusted devices feature on a new folder I shared with 3 devices: A B U (untrusted) I set up the sharing as follows: Shared the folder from A to B. Shared the folder from A to U. So far so good. Now I was trying to set up the sharing of the folder between B and U, but as I didn’t enter the password on B so the data was shared normally with U and U ended up with both e…

Original text:

I was testing the untrusted devices feature on a new folder I shared with 3 devices:

• A
• B
• U (untrusted)

I set up the sharing as follows:

• Shared the folder from A to B.
• Shared the folder from A to U.

So far so good.

Now I was trying to set up the sharing of the folder between B and U, but as I didn’t enter the password on B so the data was shared normally with U and U ended up with both encrypted and unencrypted folders (no files seem to have been transferred? More on that later).

sacnoth@untrusted-device:~/cloud/MobileCloud$ ls
0.syncthing-enc  4.syncthing-enc  8.syncthing-enc  C.syncthing-enc  G.syncthing-enc  K.syncthing-enc  O.syncthing-enc  S.syncthing-enc
1.syncthing-enc  5.syncthing-enc  Arbeit           D.syncthing-enc  H.syncthing-enc  L.syncthing-enc  P.syncthing-enc  T.syncthing-enc
2.syncthing-enc  6.syncthing-enc  A.syncthing-enc  E.syncthing-enc  I.syncthing-enc  M.syncthing-enc  Q.syncthing-enc  V.syncthing-enc
3.syncthing-enc  7.syncthing-enc  B.syncthing-enc  F.syncthing-enc  J.syncthing-enc  N.syncthing-enc  R.syncthing-enc

Arbeit was the folder I shared.

Now B, the Android Syncthing app, kept repeatedly crashing. This could have prevented any actual files from coming through. But the original folder structure was created on the untrusted device.
And U, Syncthing for desktops, reported this in the WebUI:

Failure checking encryption consistency with device <B,phone> for folder “MobileCloud” (folder-id-123): folder is configured to be encrypted but not announced thus

The message is cut off after ‘thus’ and the folder is marked ‘Out of Sync’.

It’s hard for me to see the encrypted folder / untrusted devices feature as a replacement for some other form of encrypting the folder contents when a misconfiguration (not entering the encryption password) on one device can easily bring a folder into this state.

[sacnoth]

@imsodin replied:

It is intended that you can share different folders both encrypted and plain with a single remote. It’s your responsibility to get that right. If you do not every want a specific device to get plain data, you must set the “untrusted” option on the device: This will prevent any connection with plain data to that device, even if you (mis)configure it to do so.
Should not Untrusted status be introduced? - #4 by imsodin

Sure, the problem I explained starts with me configuring one device to send encrypted data and another device to send unencrypted data.

My question is: Why did the remote accept the unencrypted data (at least the folder structure) when it knows that the folder type is: Receive encrypted?

Unfortunately I can’t set the complete remote device to ‘untrusted’ yet as I have some other folders shared with the same remote that are being synced unencrypted as I didn’t migrate them yet.

[imsodin (Simon)]

@sacnoth

My question is: Why did the remote accept the unencrypted data (at least the folder structure) when it knows that the folder type is: Receive encrypted?

That’s the bit I wanted to have in a separate topic. It really wasn’t my intention to in any way criticize you, just to keep things disentangled and thus simpler - thanks for creating this separate topic

What is the shared root path on e.g. A: Is it “…/Arbeit”, or is it the parent “…/” and “Arbeit” is one directory inside the synced folder?

@sacnoth

Now I was trying to set up the sharing of the folder between B and U, but as I didn’t enter the password on B so the data was shared normally with U and U ended up with both encrypted and unencrypted folders (no files seem to have been transferred? More on that later).

That should be impossible: When A shared to U, the folder should have been created with type “receive-encrypted” on U. Then when B shared the folder unencrypted with U, U should and apparently does reject it:

@sacnoth

And U, Syncthing for desktops, reported this in the WebUI:

Failure checking encryption consistency with device <B,phone> for folder “MobileCloud” (folder-id-123): folder is configured to be encrypted but not announced thus

The error message isn’t so nice, it has already been changed to remote expects to exchange plain data, but local data is encrypted (folder-type receive-encrypted) - I hope that is more clear, is it?

Now the question is: How did that “Arbeit” folder end up on U - I have no clue right now. Logs on U might have clues.

[sacnoth]

@imsodin

What is the shared root path on e.g. A: Is it “…/Arbeit”, or is it the parent “…/” and “Arbeit” is one directory inside the synced folder?

It’s the parent. I have created a second setup to recreate the issue and was successfully able to do so.

The folder that will be synced: SyncTest.
A folder inside of that: MyTestFolder containing MyTestFile.txt.
=> ~\SyncTest\MyTestFolder\MyTestFile.txt

1. Shared the folder from A to B unencrypted.
2. Shared the folder from A to U encrypted.
3. Shared the folder from B to U unencrypted.

This is the point where:

• B (Syncthing for Android) will start crashing.
• On U I will find the
  • encrypted:
    • directories
    • files
  • unencrypted
    • directories

syncthing@Pi3AC:~/SyncTest$ ls
2.syncthing-enc 5.syncthing-enc MyTestFolder

@imsodin

Now the question is: How did that “Arbeit” folder end up on U - I have no clue right now. Logs on U might have clues.

I have attached the logs of this test from both U and B to this post.
Log-U.txt (16.3 KB) Log-B.txt (3.1 KB)

[imsodin (Simon)]

Thanks for the clear and detailed info. What’s happening is that U is accepting indexes from B before processing the cluster-config (during which the discrepancy is noticed and acted upon). This issue came up in a different but similar context, and is pending to be fixed by lib/model: Ensure indexes are only received after checking IDs (ref #7649) by imsodin · Pull Request #7689 · syncthing/syncthing · GitHub

[sacnoth]

Okay, thanks for your help