Hacker News new | past | comments | ask | show | jobs | submit login

My biggest problem with how this feature is implemented is that the encryption passphrase is stored in plain text in the syncthing config file.

I wish there was a way to lock the passphrase in the session keyring, with syncthing only sending files to untrusted devices if the keyring is unlocked.




Is it a problem if the disk is encrypted ?


yes because more than one process can access the file.

A "password manager" provides a defined api and schields the password away from everything. It can also ask the user if process x can access the key y.


If a user has access to your machine to steal the password, why not just steal the data that's protected by it? Or add another device to syncthing? Install a keylogger. Rootkit.


Generally it depends on the threat vector.

* Do you trust the hardware

* Do you trust the OS

* Do you trust the user

* Do you trust the software

On a rootkit you don't trust the OS anymore. So a safe location inside the OS space isn't an option anymore. But often you are not a root user (e.g. android, windows in a corporate environment)

If you have OS backups there is a risk it is readable by others (e.g. cloud, different IT department). There is also a risk a user uploads the config somewhere.

If you want to rotate keys you would have to search all keys compared to a centralized location.


I wonder if some system akin to Clevis + Tang would solve this?


Not familiar with `Clevis + Tang`, but the way I would solve is my implementing an IPC mechanism where an external process can provide the encryption passphrase.

This would allow syncthing to start at boot, but untrusted devices would start in paused state. Once an external process connects and provides the passphrase (libpam module for login integration?), syncthing would start syncing devices which require the passphrase.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: