Validation (Signature and Checksum)

[schnatterer]

bin is a wonderful tool that increases security for lots of users, due to the ease of keeping tools up to date. Thanks!

Speaking of security - some tools offer checksums and or signatures on their release pages. Checking those would be a very useful addition.

Of course, difficult to implement in detail, e.g. where to get the public key to validate signatures and such. Still wanted to leave the idea here.

[marcosnils]

:100: :+1: happy to start discussions on how bin can help the world to be a more secure place :hugs:

[schnatterer]

I finally had some time to collect my ideas on this topic.

Lots of binaries are offered for download alongside checksums and signatures. It would be great if bincould check one or both of them. As there is no standard for how to create and offer checksums and signatures, I think it will not be possible to implement a simple one size fits all solution.

But I think some patterns are showing, that allow for implementing a best effort approach.

• Validating checksums: This could be rather simple.
  • One pattern I see very often is the following: Offer an additional file that appends a suffix to the actual binary download.
  • .sha256 e.g. kubectl
  • .sha256sum, e.g. helm
  • Another pattern: Collecting the checksums for multiple binaries in a single file "next to the binary"
  • sha256sums , e.g dumb-init
  • sha256sums.txt , e.g ctop
  • checksums.txt - bin :-P
  • <binary>_checksums.txt - cfssl, vegata
  • When looking at GitHub specifically we could look for any file appended to the release that contains the word checksum or sha256.
• Validating signatures. This will definitely be more challenging, because it's difficult to assume who created the signature and to find their key for validation.
  • Finding the signature itself is similar as for checksums. Looking for an .asc file on the GitHub release or look for an additional file that appends a .asc suffix to the actual binary download, e.g.
  • helm
  • dehydrated
  • But how to validate the signature? We can only guess and this makes the whole process sensitive to attack.
  • One best effort approach: Look up the person who published the release at GitHub at Keybase. This pattern would work for the two examples stated above.
  • An alternative or addition could be to look up the email from the person who tagged the release on Git level and then search for their email on a validating GPG server such as keys.openpgp.org
  • But: These approaches will work on Git (Hub) only. And: Will Keybase remain the defacto standard after having been taken over by zoom?
  • Either way, as this is only a guess who create the signature, I think we should ask the user if this person or key is the proper one and offer an option for providing a key or a link to a key for validation.

So, summing up, I think

• validating checksums could be implemented rather easy and work for most binaries that offer checksums, providing at least a certain level of valdation.
• On the other hand validating signatures will most likely cause more effort to be implemented and work only for a small number of binaries (also because only few binaries offer signatures at all).

What do you think?

Unfortunately, I won't be much help implementing this, due to lack of experience in programming in go 😞

[marcosnils]

• validating checksums could be implemented rather easy and work for most binaries that offer checksums, providing at least a certain level of valdation.

+1. Validating checksums I believe it's a feature that improves overall integrity (even though TBH almost rarely run checksums of the binaries that I download).

• On the other hand validating signatures will most likely cause more effort to be implemented and work only for a small number of binaries (also because only few binaries offer signatures at all).

I don't see a clear path provide a solution for this in the short term IMHO. Since if an attacker gets privilege access to a repository, and the CI is setup in a way that the .asc files are automatically added to the release, it really doesn't make any sense to validate signatures which denotes that IMHO there's an opportunity for Github to improve on this aspect.

Unfortunately, I won't be much help implementing this, due to lack of experience in programming in go

If you have the time and want to learn this would be a good first issue. I can offer my help to guide you what needs to be done here. We're always welcoming new contributors a new gophers :gopher: :tada:

[bureado]

Possibly related read: https://vulns.xyz/2022/05/auth-tarball-from-git/