How do people trust a service that you run? They could blindly trust that you are both honest and competent, but they shouldn't have to and you might not want to be trusted [0]. This BoF is meant for people providing (or using?) services over the network, to third-parties, and want to do so as transparently as possible. - Step 0 is simply running free software: how could one trust the service without even knowing what it does? Yet, the software itself is not enough: whether it performs as intended (in the scope of the service) and securely depends on its configuration. - The next step should be to document the setup, and publish the documentation. Unfortunately, documentation will get out of sync with the configuration, as it is wont to do. - Then, it seems intuitive to publish the configuration (as in, the entire `/etc` directory), likely kept in version control. The solution I have used so far is simply keeping `/etc` versionned in `git`, using `etckeeper`, and automatically pushing the modifications to a public repository. This approach also brings some unexpected benefits: - It make it very easy to (re)build the same infrastructure, even if it involves several systems. This is a boon, both for automated testing and for users who decide they wish to self-host the same setup. - Users can actually contribute back configuration changes, as patches/pull requests. They are not passive consumers anymore. - It is extremely convenient to use this mechanism to manage the configuration of several servers running the same service (with the same config). Some challenges I have been facing: - How to handle secrets? (cryptographic keys, credentials, ...) - How to handle automatic upgrades? (In the multi-server case) - How to prove to the user that the configuration that is published is was is actually being run? [0] By some weird cultural quirk, “trusted” is usually seen as a positive adjective. Yet, “X is trusted” means “X can break your security if compromised”: the less trust there is in a system, the more resilient it is.
Speakers: Nicolas Dandrimont nicoo