feat(security): replace keytar with @napi-rs/keyring for native OS credential storage

[proletarius101]

• Replace keytar dependency with @napi-rs/keyring v1.2.0
• Implement native OS keyring support (Secret Service on Linux, Keychain on macOS, Credential Manager on Windows)
• Add automatic detection and graceful fallback to encrypted file storage
• Replace hardcoded 'proton-drive-sync' password with SHA-256 machine fingerprint
• Remove ENCRYPTION_PASSWORD constant and KEYRING_PASSWORD env var from systemd service
• Support custom KEYRING_PASSWORD env var for Docker/headless environments

This significantly improves security on Linux by using the native Secret Service API when available, with intelligent fallback to AES-256-GCM encrypted file storage using machine-specific keys instead of hardcoded passwords.

[DamianB-BitFlipper]

Hey @proletarius101 . Thanks for the contribution. I'm currently quite busy with something else, so I won't be able to review it and test it in the coming days.

In the meanwhile, the reason to go with the file-based credential store is that for Linux users that want proton-drive-sync to start on system boot, keychains services like gnome-keyring-store only start up on user login. I tried and tried to get a decent solution working, and in the end decided to do the simple thing.

I do not know how your changes would affect this behavior. So I kindly ask if you could test this out, on linux set up start on system boot and then see if proton-drive-sync can still access the credentials and start up properly on reboot without logging in.

Thanks again.

[proletarius101]

start on system boot,

Do you mean before user log in? If that's the case, there is still a slightly more complicated way to securely cover that case (at least secure for some hardware with TPM). But before that, I just want to understand why you want it to start without user login?

[DamianB-BitFlipper]

One major way people might want to use this service is on a NAS with headless mode enabled. You may remember it from the setup command. There, no one is logging in and proton-drive-sync starts up as a system service on boot.

I would suggest thinking simple to handle the case, which is why I resorted to simply using a file for it.

[DamianB-BitFlipper]

One major way people might want to use this service is on a NAS with headless mode enabled. You may remember it from the setup command. There, no one is logging in and proton-drive-sync starts up as a system service on boot.

I would suggest thinking simple to handle the case, which is why I resorted to simply using a file for it.

[proletarius101]

One major way people might want to use this service is on a NAS with headless mode enabled. You may remember it from the setup command. There, no one is logging in and proton-drive-sync starts up as a system service on boot.

I would suggest thinking simple to handle the case, which is why I resorted to simply using a file for it.

In this case, I suggest providing a command line flag to opt out of the system keyring during setup. The program should then store a plain text credential file with root-read privilege (the user home is not loaded anyway) to offer access control, rather than fake encryption, as it hides nothing.

Update: Since you already implemented it as a file in the user home directory, it is out of the scope of this PR to provide better security for that use case. Potentially, you can have security with https://wiki.archlinux.org/title/Systemd-creds.

[DamianB-BitFlipper]

I've made some adjustments to the PR and I will try to make a reasonable solution that works for everyone.