Bluebugs
commented
2 years ago After reading about tuf, I think it would be actually the best possible solution for the repository and provide additional level of security that was not envisioned when this issue was created. go-tuf provide a client API in go that would cover a big part of our need. It seems overall that it should be actually technically compatible with what has been built already with just a few adjustment.
This is a high level idea, without having actually started working on it, on how this could be done.
- Introduce a new certified-source that provide the following API:
SetRootKey(public ed25519) GetHash() hash - Implement a tuf-source that use the go-tuf client API and provide both the Source interface and the CertifiedSource interface. It would always return an error for GetSignature.
- tuf-source will have a constructor that require a repository string and a filepath string.
- go-tuf client API would have to get a patch proposed that add a new API that return an io.Reader and file size.
- The internal apply function will have to accept something that has just a hash
- The updater code should test the provided source for the CertifiedSource interface and adjust its behaviour accordingly.
With this change a tuf repository which use an ed25519 key for root key should work with selfupdate nicely.
Right now the security of a deployment rely solely on keeping the private key out of reach of being compromised. Using a root certificate, certificate for signing binary and a list of potentially compromised certificate would significantly improve the security of using selfupdating application.