It’s good to see efforts that encourage software origin/authenticity verification, but I hope they plan to collaborate with package managing communities to make this as seamless as possible. If verification requires an extra step for software coming from a package repository (e.g. apt, pacman, zypper`), I think they’ll have a much harder time getting people on board. The best user experience is probably for the package managers to perform the third-party verification against this service between downloading and installing without requiring any user interaction (unless the user opts-out or whatever).
Just skimmed it but looks a bit too official and design-by-committee that I can estimate if it’s a good idea and/or good implemention. A standard might certainly help, although I guess most small projects didn’t do this so far not for lack of tooling. I wonder how it compares to signify, they at least made their promo material easy to digest :P
The idea is sound and not really new. Transparency logs are a great way to attest and distribute something on a public log which you can prove has not been tampered with. You only need to look at certificate transparency for this. There is existing research on the area (using apt), and existing systems that implement approximately the same thing (trustix and nixos build caches). So idea is sound, great and fairly straight forward.
Now, the new idea is connecting all this to OpenID and utilizing Trillian to implement the log. I’m personally not super fond of trillian since the storage is left as an exerciser to the reader and the two deployments we have for real world use (and with a lot of data) are both proprietary storage backends in GCP hosted by google which would be Certificate Transparency and Golang sumdb. This is problematic since there is no data or details how sigstore scales and how easy it would be to rehost logs. This is relevant if the OpenID portion becomes some form of gatekeeping of who is allowed to commit on the logs. You also want to replicate the log to ensure it’s working as intended.
So tl;dr: Not a lot of information on the technical aspects, how it would scale and how they plan to operate this.
It’s good to see efforts that encourage software origin/authenticity verification, but I hope they plan to collaborate with package managing communities to make this as seamless as possible. If verification requires an extra step for software coming from a package repository (e.g.
apt, pacman,zypper`), I think they’ll have a much harder time getting people on board. The best user experience is probably for the package managers to perform the third-party verification against this service between downloading and installing without requiring any user interaction (unless the user opts-out or whatever).Just skimmed it but looks a bit too official and design-by-committee that I can estimate if it’s a good idea and/or good implemention. A standard might certainly help, although I guess most small projects didn’t do this so far not for lack of tooling. I wonder how it compares to signify, they at least made their promo material easy to digest :P
The idea is sound and not really new. Transparency logs are a great way to attest and distribute something on a public log which you can prove has not been tampered with. You only need to look at certificate transparency for this. There is existing research on the area (using apt), and existing systems that implement approximately the same thing (trustix and nixos build caches). So idea is sound, great and fairly straight forward.
For a fun practical example kernel.org implemented transparency logs for all push operations. https://korg.docs.kernel.org/gitolite/transparency-log.html
Now, the new idea is connecting all this to OpenID and utilizing Trillian to implement the log. I’m personally not super fond of trillian since the storage is left as an exerciser to the reader and the two deployments we have for real world use (and with a lot of data) are both proprietary storage backends in GCP hosted by google which would be Certificate Transparency and Golang sumdb. This is problematic since there is no data or details how sigstore scales and how easy it would be to rehost logs. This is relevant if the OpenID portion becomes some form of gatekeeping of who is allowed to commit on the logs. You also want to replicate the log to ensure it’s working as intended.
So tl;dr: Not a lot of information on the technical aspects, how it would scale and how they plan to operate this.