On 2016-06-04(12:45:16PM+0000), ng0 wrote: > On 2016-06-04(01:17:53+0200), Ludovic Courtès wrote: > > Hi! > > > > Mike Gerwitz skribis: > > > > > On Fri, Jun 03, 2016 at 18:12:47 +0200, Ludovic Courtès wrote: > > >> First, ‘git pull’ doesn’t do it for you, you have to pass ‘--verify’ and > > >> there’s no way to set it globally. > > > > > > That's unfortunate. Does your checkout scenario include a fresh clone? > > > If so, a pull flag wouldn't help there. > > > > > > Leo mentioned a patch; I don't think that'd be too difficult (looking at > > > other config options in builtin/pull.c), and would be a great idea. It > > > appears to pass it off to merge.c; that might be a useful area to verify > > > signatures as well (pull being a fetch && merge/rebase), in a general > > > sense. > > > > Yeah, it wouldn’t be too hard to add to Git proper, I think, but we > > can even live without it initially. > > > > >> Second, even if it did, it would be a shallow check: as Mike notes in > > >> with the ‘signchk’ > > >> script, you actually have to traverse the whole commit history and > > >> authenticate them one by one. But that’s OK, it runs in presumably less > > >> than a minute on a repo the size of Guix’s, and we could also stop at > > >> signed tags to avoid redundant checks. > > > > > > Practically speaking, that's probably fine, though note that a signed > > > tag is just a signed hash of the commit it points to (with some > > > metadata), so you're trusting the integrity of SHA-1 and nothing > > > more. > > > > > > With that said, the tag points to what will hopefully be a signed > > > commit, so if you verify the signature of the tag _and_ that commit, > > > that'd be even better. Git's use of SHA-1 makes cryptographic > > > assurances difficult/awkward. > > > > > > An occasional traversal of the entire DAG by, say, a CI script would > > > provide some pretty good confidence. I wouldn't say it's necessary for > > > every pull. > > > > Agreed. > > > > >> Third, as I wrote before¹, relying on the OpenPGP web of trust to > > >> determine whether a commit is “valid” is inappropriate: what we want to > > >> know is whether a commit was made by an authorized person, not whether > > >> it was made by someone who happens to have an OpenPGP key directly or > > >> indirectly certified. > > > > > > If you want to keep with the convenience of the web of trust, then you > > > can have a keyring trusting only the appropriate Guix > > > hackers. Otherwise, I agree. > > > > Oh right, we could do something like: > > > > gpgv --keyring guix-developers.keyring foo > > > > (I realize GSRC uses this idiom already when authenticating source > > tarballs: > > .) > > > > >> Fourth, there’s inversion of control: ‘git log’ & co. call out to ‘gpg’, > > >> so if we want to do something different than just ‘gpg --verify’, we > > >> have to put some other ‘gpg’ script in $PATH. Blech. > > > > > > What types of things are you considering? > > > > Something as simple as this: > > > > --8<---------------cut here---------------start------------->8--- > > $ git config gpg.program 'gpgv --keyring /dev/null' > > $ git verify-commit HEAD > > error: cannot run gpgv --keyring /dev/null: No such file or directory > > error: could not run gpg. > > --8<---------------cut here---------------end--------------->8--- > > > > :-/ > > > > >> Seventh, even if it did, what would we do with the raw ASCII-armored > > >> OpenPGP signature? GPG and GPGME are waaaay too high-level, so we’d > > >> need to implement OpenPGP (in Guile, maybe based on the OpenPGP library > > >> in Bigloo?)?! > > > > > > What about gpgme/libgcrypt?[*] > > > > I believe, but haven’t checked carefully, that GPGME is too high-level; > > libgcrypt is too low-level (it does not implement OpenPGP.) > > > > > [*]: I was actually considering writing an FFI for libgcrypt (if it > > > doesn't exist already), but it made me uncomfortable without studying > > > whether Guile can make assurances that pointer-referenced data in > > > "secure" memory will never be copied anywhere else. I was going to > > > bring it up in the near future on the guile mailing list after I did > > > some research myself; no need to derail the discussion here. > > > > We have incomplete libgcrypt bindings: > > > > http://git.savannah.gnu.org/cgit/guix.git/tree/guix/pk-crypto.scm > > > > This is used for the authentication of substitutes: > > > > https://www.gnu.org/software/guix/manual/html_node/Substitutes.html > > > > Thanks for your feedback! > > > > Ludo’. > > > > > > > > Aside from other problems, > Couldn't we create a separate gpg(-1,-2) package which installs its own GPG_HOME_DIR > and keyring (gpg2 or gpg1 must be present for that, for future purposes a > gpg2 would be best I think)? > > One example: > https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Features#Validated_Portage_tree_snapshots > > I know this isn't similar to what we want to do, but it might serve as an example. > The method described in the link downloads an auto-signed tarball snapshot of the > portage directory via webrsync. The keys are also visible on the wiki and it is up > to users to put trust in them, as this method is considered optional. > The source used for this is https://gitweb.gentoo.org/proj/gentoo-keys.git/tree/README.md > > Maybe this helps a bit. > Adding to this what I just found: http://www.tedunangst.com/flak/post/signify https://github.com/aperezdc/signify I am /not/ sure if this will be useful for what guix secure pull wants to achieve, but maybe there's some inspiration to be found in the source. -- ♥Ⓐ ng0 For non-prism friendly talk find me on psyced.org / loupsycedyglgamf.onion