search

ktemkin / gnuradio-for-mac-without-macports

GNURadio bundled as an app for Mac OS X (does not require MacPorts)
GNU General Public License v3.0
323 stars 45 forks source link

Add Signatures to Binary Releases #32

Open cfriedt opened 7 years ago

cfriedt commented 7 years ago

anything that's using HTTP was done as a result of the author's original ignorance of "curl -L". Any site that does not have a corresponding HTTPS service can be augmented with CKSUM (for packages). I do not believe that git:// urls are affected, but we should actually exit with an error condition for any http:// git repositories (and instead rewrite the URL to use HTTPS).

dholl commented 7 years ago

https isn't completely secure either. Here's a fantastic eye-opener on the algorithmic and systemic insecurities of the whole Certificate Authority mess: https://www.eff.org/observatory https://www.eff.org/mention/eff-tens-thousands-websites-ssl-offers-effectively-no-security

Aside: For the moment, I personally only tend to trust gpg-signed objects (assuming the signer didn't use outdated algorithms), or second to that for my own development needs, I prefer sides whose domains are secured with DNSSEC, and have https certificates that can be verified against TLSA records. --- GitHub fails here, as do many other sites. One notable exception are the folks at Debian project appear to employ the right level of paranoia, from DNSSEC/TLSA web servers to gpg signatures against their package repos, to reproducible builds. That project is thorough. ;)

Getting back to this project (gnuradio-for-mac-without-macports), a great start would be requiring that we've computed SHA-256 for every package source (non-git) (easy, via shasum -a 256 -- blah.tar.gz), and then for major releases of GNURadio.app, we'd put out a gpg-signed tag on the repository at each release: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

That way, the signed tag protects the code (build.sh and friends) as well as the SHA-256 hashes and git hashes contained within that code.

And ideally for each pre-compiled release .dmg file, we'd have a .asc (detached ascii-armored signature) for each as well --- for those folks who don't want to run build.sh themselves.

So, to summarize, I think this level ought to suffice for the moment, for a balance of minimal effort on our end vs protecting most folks from most nuisances:

  1. Include SHA-256 hashes for all downloaded sources
  2. gpg-sign a tag at each major release
  3. include detached (.asc) signature for each released .dmg
cfriedt commented 7 years ago

Going to rename this issue, because the points that @dholl brought up are still relevant even after using https for everything.