#10884 Hidden encryption password added when accepting a plain folder in v2.1.5

What happened?

Summary

On a fresh Syncthing v2.1.5 Windows installation, accepting a folder shared without encryption resulted in the Windows device's own folder-device record containing an encryption password.

The sharing encryption field appeared blank in the GUI throughout. This caused the peers to disconnect with encryption-consistency and cluster-configuration errors.

Clearing encryptionPassword for all folder-device records through the live REST API immediately resolved the problem and synchronization succeeded.

Steps to reproduce

Start fresh Syncthing v2.1.5 installations on Linux and Windows.
Pair the devices without sharing folders and confirm that both show Connected (Unused).
On Linux, create a Send Only folder and share it with Windows. Leave the sharing encryption password empty.
On Windows, accept the folder as Receive Only.
The sharing encryption field appears blank. Explicitly focus it, select all and delete before saving.
Observe that the devices connect briefly and then disconnect without transferring the file.
Query the live Windows folder configuration using:

GET /rest/config/folders/<folder-id>

Actual behaviour

The Windows folder's remote/source-device record had no encryption password, but its local/self device record returned Syncthing's fixed nine-character secret-redaction placeholder. This indicated that a secret was stored even though the GUI field had remained blank.

The Linux peer repeatedly reported that the Windows peer's cluster configuration omitted the required remote-device information. An earlier attempt also reported that the Windows folder was locally encrypted while the remote expected plain data.

The issue survived:

Index database resets on both devices.
Complete configuration-directory resets.
Generation of new device identities.
Creation of a new folder with a new Folder ID.
Microsoft Edge InPrivate mode.
Disabling Edge password autofill.
Explicitly selecting and deleting the contents of the visibly blank sharing-encryption field before saving.

Expected behaviour

Accepting a shared folder with an empty sharing-encryption field should create plain folder-device records on the receiving device. No encryption password should be stored, and the folder should synchronize normally.

Workaround

I fetched the receiving folder through the REST API, set encryptionPassword to an empty string for every entry in its devices collection, and PUT the complete folder object back to:

/rest/config/folders/<folder-id>

The live API then reported no stored secret for either device. The peers immediately remained connected and synchronized successfully.

Subsequent tests also passed:

Initial file replication.
Replacement of the source file.
Staggered retention of the previous version.
Propagated source deletion.
Recovery of the deleted file from the destination's version store.

Additional notes

Both devices were running the same Syncthing version.
Direct TCP connectivity and TLS negotiation worked before the failure.
Device pairing without a shared folder remained stable as Connected (Unused).
The failure appeared only after accepting the shared folder.
Sensitive device IDs, addresses and API credentials have been omitted.

Syncthing version

v2.1.5 on both devices

Platform & operating system

Linux Debian 13 VM and Windows 11 --Source: official syncthing/syncthing:latest Linux AMD64 container Destination: Syncthing Windows AMD64 installed through winget (Syncthing.Syncthing)

Browser version

Edge Version 153.0.4234.32 (Official build) (64-bit)

Relevant log output

Linux/source:

Device sent cluster-config without the device info for the remote
Lost device connection: handling cluster-config: remote device missing in cluster config

Windows/destination, from an earlier acceptance attempt:

Failed to verify encryption consistency: remote expects to exchange plain data, but local data is encrypted (folder-type receive-encrypted)