private key of default server agent is stored in cleartext

[jonassmedegaard]

atomic-server stores password in cleartext in its config file.

That may be acceptable (or even needed) for some scenarios, but please support secure storage - and preferably by default and documented as the recommended way.

Seems keyring is suitable for this.

[joepio]

Yeah it's definitely a weak spot, although I'm not entirely sure how I can provide enough convenience with a tool like keyring.

Users should be able to read and set their private key in an easy way. If the key itself is stored with keyring, where can users find it? Maybe I'll need to add commands to both atomic-cli and atomic-server for setting and reading the key? Or is there a different way?

[jonassmedegaard]

I don't know keyring, only the XDG protocol used for the linux backend - and there normal user experience has an independent approval interface pop up when your tool wants to fetch a secret. I.e. it is optimized for use as a desktop-oriented daemon.

Perhaps it is helpful to discuss issues like this one, if you document the types of scenarios you want to support with the daemon and CLI tool.

As I understand it, you want to support at least three scenarios:

1. self-contained system daemon - network-accessible with auto-created ACME certificate
2. backend system service - accessible only from a frontend web service, either without using the ACME feature or optionally compiled without support for it at all
3. self-contained desktop service - run by a local users and accessible only at localhost (unencrypted, assuming that user is the only one on that host)

As I see it, at least scenario 3) should use keyring but some might also want their system services to store secrets on special devices, e.g. on an external USB-connected storage that needs to be plugged in when services are started, and then is unplugged again - expecting secrets to only ever reside in protected memory blocks.

[joepio]

The risks

The private key is created by the server (if none existing is found) and used to sign all changes that the server makes by itself. If the server creates new resources, they are signed using this key.

If someone else gets their hand on that key, they could impersonate the server.

Also, if a user would use their own personal key as the default server agent (which is what I did on atomicdata.dev), getting read access to the server would also imply impersonating the user.

Using something like keyring

• This means that when the server starts, a prompt will be given (on macos, at least) asking for access to some credential store.
• If users want to read their private key, for example to re-use it somewhere else, they will need to have some new interface. Maybe this is a bad idea, and we should not have this access at all. It would be simpler if we can only write to the key store.