Publicly-auditable/editable services

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.

• Notes