On Wed, Mar 02, 2016 at 10:03:59AM -0800, Christopher Allan Webber wrote: > Right now, when a user does a "guix pull", that pulls down the latest > repository of code from git, which is kept in a tarball. Once you > receive the latest code, this has some checks: what's the hash of each > package, etc.
A discussion worth having. But, let's merge this bug into debbugs.gnu.org/22629. Also, we should read "The Update Framework" as requested there. > > Unfortunately, it's delivered over http: > > (define %snapshot-url > ;; "http://hydra.gnu.org/job/guix/master/tarball/latest/download"; > "http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz"; > ) > > At minimum we should deliver this over HTTPS, ideally with a single > certificate that is trusted by the user, so the user can't be easily > MITM'ed. > > On top of that, even if you run from git proper what there isn't a test > about is: can you trust those latest commits? Git doesn't really check, > at least by default. > > https://mikegerwitz.com/papers/git-horror-story > > How about this: anyone with commit access should use "signed off by" and > gpg signatures combined. We should keep some list of guix committers' > gpg keys. No commit should be pushed to guix without a gpg signature. > At this point, at least, there is some possibility of auditing things. > > Perhaps before a master.tar.gz is made, there can be some integrity > check of the commits matching the current set of "trusted" keys? > > >
