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 . 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
/etcdirectory), likely kept in version control. The solution I have used so far is simply keeping
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?
 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.