Server secret key

[modem7]

Heya,

Unsure if this is possible/wanted/otherwise:

I'm currently using the LSIO Docker image for the hishtory server, and I wonder if it would make sense for the server to generate/output a secret key on first install/each time it's started?

So on the clients, we'd set:

export HISHTORY_SERVER=http://my-hishtory-server.example.com
export HISHTORY_KEY=SERVER-UUID

Then do an init on the clients.

This would make programmatic installs a lot faster across the board. But I'm unsure how feasible or wanted this is due to the end-to-end nature of hishtory.

If this feature is not to be implemented due to the above, please close!

[David Dworken]

As a general feature, this does seem to me like it goes against the goal of supporting end-to-end encryption (since the server should never know any client's keys). Admittedly, this isn't necessarily relevant in a self-hosting context when the server is run by the same entity as the clients, but it does still seem like a worthwhile principle.

Though I'm curious: what is the motivation behind this request? Is the goal to ensure that clients cannot register against the backend server if they don't have the key? If so, that seems like something we could support, but I'm curious if an alternative solution is to either:

• Use the HISHTORY_MAX_NUM_USERS environment variable to limit the number of users (e.g. setting it to one ensures that once you've registered, no other users will be able to register with the backend)
• Deploying the backend behind a load balancer, and using the load balancer to add authentication requirements (e.g. a basic solution would be to use HTTP basic auth [example])

[modem7]

Heya,

The main reason was a simple one:

Ease of use for first time users using the docker image.

Granted, getting the UUID is quite simple on the clients, so this isn't a make or break request.

My initial idea was as follows:

The server generates a UUID, but doesn't store it, it was more for the following workflow:

1. Server gets created
2. A UUID is generated with uuidgen or similar (however you currently do it), but this isn't stored, merely displayed in stdout
3. When rolling out clients, you wouldn't need an initial client to get the UUID to apply to other clients, as you'd use the initial value the server gives.

But in all honesty, given the e2e ethos, the more I think about it, the more it goes against that, even if it is just output to stdout or similar, which makes it difficult to justify, even if it is arguably simple to implement.

I'd say close the ticket unless you see any value add from it.

[David Dworken]

Got it, thanks for the explanation! While I agree this could be done and it might simplify the installation flow, I'm also inclined to skip it to stay aligned with the e2e ethos. Thanks for the feedback and discussion!