From: Christopher Allan Webber <cwebber@dustycloud.org>
To: bug-guix@gnu.org
Subject: Trustable "guix pull"
Date: Wed, 02 Mar 2016 10:03:59 -0800
Report forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Wed, 02 Mar 2016 18:05:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Christopher Allan Webber <cwebber@dustycloud.org>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Wed, 02 Mar 2016 18:05:02 GMT) (full text, mbox, link).
Message #5 received at submit@debbugs.gnu.org (full text, mbox, reply):
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.
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?
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Wed, 02 Mar 2016 19:27:02 GMT) (full text, mbox, link).
Message #8 received at 22883@debbugs.gnu.org (full text, mbox, reply):
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? > > >
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Wed, 02 Mar 2016 21:08:02 GMT) (full text, mbox, link).
Message #11 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Leo Famulari writes:
> 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.
I'm not sure they should be merged, though they're related. That thread
doesn't deal at all with security, though it provides some other good
ideas. It even says:
PS: I do not mention the issue of authenticating code here, which is
obviously very important and deserves to be treated separately.
However I have no objections to merging them if others think we should
> Also, we should read "The Update Framework" as requested there.
This? https://theupdateframework.github.io/
There seem to be quite a few papers there!
Severity set to 'serious' from 'normal'
Request was from ludo@gnu.org (Ludovic Courtès)
to control@debbugs.gnu.org.
(Thu, 17 Mar 2016 23:01:01 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 25 Apr 2016 22:26:02 GMT) (full text, mbox, link).
Message #16 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hello! Christopher Allan Webber <cwebber@dustycloud.org> skribis: > 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. To make progress on this front, I’ve decided to start signing all my commits, so: --8<---------------cut here---------------start------------->8--- $ git config commit.gpgsign true $ git config --global user.signingkey 090B11993D9AEBB5 --8<---------------cut here---------------end--------------->8--- I invite everyone to do the same. Hopefully, within a few weeks, we can add a commit hook to reject unsigned commits. Note that we’ll be signing patches we push on behalf of contributors who do not have commit access (reviewer’s responsibility). Also, rebasing, amending, and cherry-picking code signed by someone else would lose the original signature, which isn’t great and should be avoided, if possible. What remains to be seen, among other things, is how we’ll maintain a keyring of the committers, and how we’ll distribute it to users of ‘guix pull’; the TUF spec has clever ideas about it, but we need to see how they map to our setup. Thoughts? Ludo’.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 26 Apr 2016 00:14:02 GMT) (full text, mbox, link).
Message #19 received at 22883@debbugs.gnu.org (full text, mbox, reply):
On Tue, Apr 26, 2016 at 12:25:11AM +0200, Ludovic Courtès wrote: > Hello! > > Christopher Allan Webber <cwebber@dustycloud.org> skribis: > > > 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. > > To make progress on this front, I’ve decided to start signing all my > commits, so: > > --8<---------------cut here---------------start------------->8--- > $ git config commit.gpgsign > true > $ git config --global user.signingkey > 090B11993D9AEBB5 > --8<---------------cut here---------------end--------------->8--- > > I invite everyone to do the same. Hopefully, within a few weeks, we can > add a commit hook to reject unsigned commits. Okay. > Note that we’ll be signing patches we push on behalf of contributors who > do not have commit access (reviewer’s responsibility). > > Also, rebasing, amending, and cherry-picking code signed by someone else > would lose the original signature, which isn’t great and should be > avoided, if possible. I think it's common to make minor edits when committing on behalf of others. For example, the committer might clean up a commit message or standardize indentation. How should we handle this?
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 26 Apr 2016 00:18:01 GMT) (full text, mbox, link).
Message #22 received at 22883@debbugs.gnu.org (full text, mbox, reply):
On Mon, Apr 25, 2016 at 8:13 PM, Leo Famulari <leo@famulari.name> wrote: > I think it's common to make minor edits when committing on behalf of > others. For example, the committer might clean up a commit message or > standardize indentation. > > How should we handle this? You would sign the commit yourself if you are committing on behalf of someone else. - Dave
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 26 Apr 2016 07:13:01 GMT) (full text, mbox, link).
Message #25 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hello! "Thompson, David" <dthompson2@worcester.edu> skribis: > On Mon, Apr 25, 2016 at 8:13 PM, Leo Famulari <leo@famulari.name> wrote: > >> I think it's common to make minor edits when committing on behalf of >> others. For example, the committer might clean up a commit message or >> standardize indentation. >> >> How should we handle this? > > You would sign the commit yourself if you are committing on behalf of > someone else. Right. The (minor) issue I was referring to arises when one committer massages signed commits from another committer. Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 30 Apr 2016 06:57:01 GMT) (full text, mbox, link).
Message #28 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hey, guys. Chris mentioned this thread to me. I'm happy to see the discussion! Chris: unfortunately, my `mml-secure-openpgp-encrypt-to-self` flag somehow got unset when I sent you my reply, so I can't read my own message. But I'll rewrite some of it here. On Mon, Apr 25, 2016 at 20:13:59 -0400, Leo Famulari wrote: >> Note that we’ll be signing patches we push on behalf of contributors who >> do not have commit access (reviewer’s responsibility). >> >> Also, rebasing, amending, and cherry-picking code signed by someone else >> would lose the original signature, which isn’t great and should be >> avoided, if possible. > > I think it's common to make minor edits when committing on behalf of > others. For example, the committer might clean up a commit message or > standardize indentation. > > How should we handle this? You don't. One of the core purposes of digital signatures is to ensure integrity of the signed data: if I submit a patch, I don't want someone else modifying it and saying it was my own, or saying it was modified without supplying a diff; that'd be a misrepresentation; a horror story almost. ;) The question is for what purpose you're signing commits. Chris mentioned trust, but that can come in a few different forms. Signatures ensure: - Authentication: whether the commit came from a trusted source; - Integrity: assurance that the commit has not been modified; and - Non-repudiation of origin: the signer cannot deny signing it. If you only care about authentication, then it doesn't matter if the signature is retained---it only matters that the person who eventually signs off on the commit is trusted. In that case, just sign it. If it's integrity, then make another commit that changes the original. I recommend this regardless, for the reason I stated above; just branch, apply their commits, your change, and merge. For non-repudiation assurances, you'll need to keep the original signature as well. This might be useful, say, in the case of issues with copyright assignments---maybe an employer holds copyright on the code and the employee claims he/she isn't the person that actually submitted it. All of this subject to the usual crypo-caveats (no compromised private key, yadda yadda). Now, what is being signed isn't actually the code---it's the contents of the commit object, which includes a SHA-1 hash of the tree, parent commit(s), author, committer, timestamp, and commit message: --8<---------------cut here---------------start------------->8--- $ git cat-file -p 7062845 tree 7d21b900c0773d7fdc898aecff11053a910ac18d parent 2b56dc019a049b2f68ce078b243fc313fbaeacf3 author Ludovic Courtès <ludo@gnu.org> 1461943404 +0200 committer Ludovic Courtès <ludo@gnu.org> 1461945944 +0200 gpgsig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 [...] -----END PGP SIGNATURE----- nls: Add Simplified Chinese translation. [...] --8<---------------cut here---------------end--------------->8--- My point with this[*] is that the GPG signature you receive isn't meaningful in the case of a rebase---if it signed blobs or a diff, maybe it would be. But since rebasing will eventually cause the GPG-signed commit to be GC'd (unless there's a ref to it), you can't modify the commit and just reference the old diff with the original signature. More details in a discussion with Whonix here: https://web.archive.org/web/20150619232904/https://www.whonix.org/forum/index.php?topic=538.msg4278#msg4278 So if you do want to clean up or squash GPG-signed changes from contributors, or do other rebasing, then I'd either push back and tell them to do it, or maybe have them send GPG-signed _patches_ to a public mailing list where it can be permanently archived; then everyone can see the original. [*] SHA-1 was never intended to be used as a security measure in Git---nor should it be; SHA-1 is effectively broken with the demonstration of a freestart collision last year (where the attacker controls the IV; but it's only a matter of time). So if a collision can be found for any of those signed SHA-1 hashes---or any hashes they reference---_that actually makes sense to Git and humans_, then your signature will still be perfectly valid. But distribution archives are also GPG-signed, so Git will never be the only place of reference. I need to update my article, but I'm essentially saying that it's really hard to have strong cryptographic assurances with Git even with signed commits---that attack surface is simply too large, as I mentioned in the Whonix discussion. Realistically, it's extremely unlikely that something will ever happen, but until Git switches to a secure hash algorithm (...har har), don't expect full integrity. If you're using signatures for authorization primarily, then you don't really need to worry. -- Mike Gerwitz Free Software Hacker | GNU Maintainer & Volunteer https://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 16 May 2016 17:39:02 GMT) (full text, mbox, link).
Message #31 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Please, for the love of all/any gods!(if any) Fix this issue :) For example, you can get this https to work: https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz (it doesn't currently) $ wget https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz --2016-05-15 15:32:15-- https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz Resolving git.savannah.gnu.org... 208.118.235.72 Connecting to git.savannah.gnu.org|208.118.235.72|:443... connected. OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol Unable to establish SSL connection. Chromium says: This site can’t provide a secure connection git.savannah.gnu.org sent an invalid response. Learn more about this problem. ERR_SSL_PROTOCOL_ERROR This works just fine though: https://savannah.gnu.org/ and https://gnu.org/ and https://www.gnu.org/ As a reminder, letsencrypt and startssl are a thing - both provide free certs. If that's the issue. But I presume there must be another reason why there's no https, therefore would you please consider hosting it somewhere like github? or if github isn't inline with GNU(for whatever reasons, eg. license), then surely notabug.org is(according to libreboot which recommends it instead of github)! Please, pretty please, consider it. At the very least you could host a mirror/clone there(if not make it the permanent home of the repo.) and someone(a dev) could push to both without even having two remotes(ie. just the origin remote with two push urls is okay); so when push-ing, both savannah and notabug would get updated(see below how), and thus we(the users) could use the notabug link to get master.tar.gz which would then be https. It would be something like this: https://https://notabug.org/guixuser/guix/archive/master.tar.gz (so it's .gz not .xz, is that worse than serving it over plain http?) I would actually recommend github for increased reliability, but whatever! As long as it's not served over http anymore! Or find some way of signing it? that's going to be harder than this! Here's how to have two push refs in the same remote(origin): Suppose that this git remove -v show shows this: origin https://github.com/gorhill/uMatrix.git (fetch) origin https://github.com/gorhill/uMatrix.git (push) Then to add another push url to the same origin remote, you'd do: re-add the already existing push url(from above): git remote set-url --add --push origin https://github.com/gorhill/uMatrix.git now, this git remote -v show would show no changes! and now add the new one: git remote set-url --add --push origin git@notabug.org:somethingelse/uMatrix.git and now, this git remote -v show would show: origin https://github.com/gorhill/uMatrix.git (fetch) origin https://github.com/gorhill/uMatrix.git (push) origin git@notabug.org:somethingelse/uMatrix.git (push) So when you do 'git push', it will push to both (so it will prompt for your ssh key password twice). Of course for you the 'https://' urls from above would be 'git@' instead! (they just happen to be https for me, since I don't have push access) I want to be honest here: this bug is a show stopper for me! It makes me draw certain unfavorable conclusions about the mentality and seriousness of the guix project devs. I wish it wouldn't, but really can you blame me? I want to use guix but not until something's done about this so that MITM is unlikely to happen here. At the very least let me pull this over https, please! If you use notabug.org then not only we(the users) can get/clone the git repo over https, but we can also get/clone it over ssh! (instead of over just plain git://). So that'd be two rabbits in one shot! Please let me know if anything is going to be done about this, so that I would know what to do next: wait or move on. No hard feels. Presumably any direct answer would be better than no answer, so that I would know what to do, rather than waste time waiting for an answer... Thank you and I appreciate your time in reading all this! -signed, an idiot. ;-) #whohasselfesteemamirite
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 16 May 2016 17:57:02 GMT) (full text, mbox, link).
Message #34 received at 22883@debbugs.gnu.org (full text, mbox, reply):
On Sun, May 15, 2016 at 8:40 AM, <fluxboks@openmailbox.org> wrote: > Please, for the love of all/any gods!(if any) > Fix this issue :) > For example, you can get this https to work: > https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz > (it doesn't currently) > > $ wget https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz > --2016-05-15 15:32:15-- > https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz > Resolving git.savannah.gnu.org... 208.118.235.72 > Connecting to git.savannah.gnu.org|208.118.235.72|:443... connected. > OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol > Unable to establish SSL connection. > > Chromium says: > This site can’t provide a secure connection > > git.savannah.gnu.org sent an invalid response. > Learn more about this problem. > ERR_SSL_PROTOCOL_ERROR > > This works just fine though: https://savannah.gnu.org/ and https://gnu.org/ > and https://www.gnu.org/ > > As a reminder, letsencrypt and startssl are a thing - both provide free > certs. If that's the issue. We *DO NOT* run Savannah, the FSF does. Savannah absolutely should allow cloning Git repositories over HTTPS, but we are the wrong people to complain to about it. You can send a polite message to sysadmin@gnu.org instead. > I want to be honest here: this bug is a show stopper for me! It makes me > draw certain unfavorable conclusions about the mentality and seriousness of > the guix project devs. I wish it wouldn't, but really can you blame me? Yes, I can. I think you should re-evaluate your conclusions. All of our official release tarballs are GPG signed, we have begun signing all of our commits, all of our package recipes validate checksums for the source code they download, and we patch CVEs in a pretty timely manner for a such a small core team. I can assure you that we are very serious about security. I recommend simply not using 'guix pull' right now until we have something more trustable, which we are working on! This is beta software written by volunteers. The problem will be solved quicker with some more hands to help. Would you like to join in? - Dave
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 17 May 2016 21:20:02 GMT) (full text, mbox, link).
Message #37 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi! fluxboks@openmailbox.org skribis: > But I presume there must be another reason why there's no https, HTTPS is not the alpha and omega of security. At best, it provides confidentiality and allows users to authenticate the server (some certificate authorities are corrupt though, so there’s a risk.) Once you’ve authenticated the server, you still haven’t authenticated the code, which is what you’re really interested in as a user. So this is what this issue is about, and I agree it needs to be fixed ASAP. Your contributions are very welcome, too! :-) Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Wed, 01 Jun 2016 16:48:01 GMT) (full text, mbox, link).
Message #40 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hello!
Here are some (somewhat unstructured!) thoughts about what it means to
deliver secure updates to Guix users, and how The Update Framework (TUF)
and related ideas can help us.
To summarize, the problem we’re trying to solve is the “secure” update
of Git checkouts. That’s because Guix is a set of recipes and code that
is delivered to users/developers using Git.
More specifically, we share most of the security goals listed in
Sections 1.5.2 and 1.5.3 of the TUF spec¹.
TUF is biased towards repositories of binary packages and associated
meta-data, whereas we’re (1) using Git, and (2) concerned with source
code authentication. Thus, some of the goals in 1.5.2 are not
applicable, as we will see, and some of the roles in 2.1 are not
applicable either.
The OPAM folks came up with a variant of TUF² that takes advantage of
the fact that the OPAM package repository is in a Git repo³ (this design
is not currently used by opam-repository, AFAICS). Their scheme uses
detached signature files for package meta-data instead of signed
commits; thus, it is not concerned with Git checkout authentication in
general, but with the authentication of individual files in the repo
(see the discussion of “target files” below). Yet, there are good ideas
applicable to our Git repo, such as the ‘signed’ tag created by a
“signature bot” and that clients can use to check whether they get the
latest version of opam-repository.
The Qubes folks have their own process⁴, not inspired by TUF. They push
signed Git tags (instead of signing commits), with roughly one signed
tag every time a bunch of commits is pushed⁵. AIUI, Qubes uses the
OpenPGP web of trust to determine which keys are authorized keys: a key
signed by the Qubes master key is considered authorized. IMO this is a
misuse of OpenPGP, where a signature on a key is a statement of trust in
(certification of) the key/email and possibly key/name bindings⁶, and
has nothing to do with authorization.
At the very least, it’s clear that:
1. Guix clients, whether ‘guix pull’ or ‘git pull’, must be able to
authenticate the history of their checkout; this is why we started
signing commits.
2. We must use a mechanism such as the ‘signed’ Git tag described in
the OPAM document so that clients can know what the latest Guix
commit is.
3. We must follow the key management practices developed in TUF.
Let’s go back to the “goals for specific attacks to protect against” in
Section 1.5.2 of the TUF spec, and see how they apply to the
distribution of Guix’s source tree:
1. “Rollback attacks. Attackers should not be able to trick clients
into installing software that is older than that which the client
previously knew to be available.”
As explained in the OPAM document, Git gives us linearity
guarantees (‘git pull’ makes sure we move forward), so clients can
be sure they move forward in Guix history. We expect clients to
authenticate the Git history, making sure all the commits are
signed by authorized Guix committers.
To perform such an attack, an attacker would need to get access to
the private key of one of the authorized committers. We can
probably consider it beyond the scope of our threat model, because
at this point, the attacker could do anything (like the 2nd
paragraph of TUF Section 2.2 suggests) and the version string of
packages is really a detail.
2. “Indefinite freeze attacks. Attackers should not be able to
respond to client requests with the same, outdated metadata without
the client being aware of the problem.”
3. “Endless data attacks” and “Slow retrieval attacks” seem to be
beyond the scope of our interests here; TUF does not seem to
address them either.
4. “Extraneous dependencies attacks. Attackers should not be able to
cause clients to download or install software dependencies that are
not the intended dependencies.”
Not applicable: we’re distributing a Git source tree, not build
artifacts.
5. “Mix-and-match attacks. Attackers should not be able to trick clients into
using a combination of metadata that never existed together on the
repository at the same time.”
Not applicable, for the same reaons.
6. “Malicious repository mirrors should not be able to prevent updates
from good mirrors.”
Clients should check the age of the ‘signed’ tag, and thus detect
outdated mirrors.
Section 2 of the TUF spec defines the notion of “target files” and
discusses roles and the PKI.
“Target files” are defined as files distributed by the system as
commonly found in “traditional” package repos (e.g., binary packages and
associated meta-data); they are the unit of authenticable data.
In Guix we want to authenticate whole checkouts, so the notion of
“target file” seems to make little sense. For instance, it wouldn’t
make sense to sign each gnu/packages/*.scm file individually, because
the meaning of these files depends not only on the surrounding files,
but also on the core of Guix, such as the (guix packages) module, which
defines the very notion of “package”.
The PKI and roles described in TUF, with separate responsibilities and
the ability to delegate, make a lot of sense (it’s similar in spirit to
SPKI⁷, but more limited in scope.) Some of the roles do not seem to be
applicable to secure Git update delivery:
• the “targets” role is not applicable, at least not to individual
source files;
• the “snapshot” role does not seem applicable (a Git commit *is* a
complete snapshot); the “timestamp” role, though, corresponds to the
signature bot described in the OPAM document;
• the optional “mirrors” role doesn’t seem very useful, as
acknowledged by Section 2.1.5 of the TUF spec.
With that in mind, we now need to see how to map the relevant bits of
TUF to Guix!
Comments welcome!
Ludo’.
¹ https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt
² http://opam.ocaml.org/blog/Signing-the-opam-repository/
³ https://github.com/ocaml/opam-repository
⁴ https://www.qubes-os.org/doc/verifying-signatures/
⁵ See for example all the ‘mm_XXX’ tags at
<https://github.com/QubesOS/qubes-core-agent-linux/releases>.
⁶ https://tools.ietf.org/html/rfc4880#section-5.2
⁷ http://theworld.com/~cme/spki.txt
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 03 Jun 2016 16:14:01 GMT) (full text, mbox, link).
Message #43 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hello! So we sign Git commits, and now we want to authenticate Git checkouts. There’s a series of bad news. First, ‘git pull’ doesn’t do it for you, you have to pass ‘--verify’ and there’s no way to set it globally. Second, even if it did, it would be a shallow check: as Mike notes in <https://mikegerwitz.com/papers/git-horror-story> 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. 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. IOW, we want to know whether the key used to sign the commit is among the authorized developer keys. 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. Fifth, even if we did that, we’d be stuck parsing the possibly l10n’d output of ‘gpg’. Pretty fragile. Sixth, OK, we’ll use libgit2, and write Guile bindings, maybe based on the CHICKEN bindings², easy! Well no, it turns out that libgit2³ has no support for signed commits (the ‘signature’ abstraction there has nothing to do with OpenPGP signatures.) 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?)?! I hope I’m just being negative and I missed an obvious solution or made wrong hypotheses. Please tell me! :-) I stumbled upon git-lockup⁴, which uses something other than OpenPGP to sign objects in Git. However, signatures are not stored in commits but rather in “git notes”, which, IIUC, are mutable objects detached from the rest of the object store, so not great. Cheers, Ludo’. ¹ http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#40 ² http://wiki.call-cc.org/eggref/4/git ³ https://libgit2.github.com/libgit2/ ⁴ https://github.com/warner/git-lockup
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 03 Jun 2016 20:18:01 GMT) (full text, mbox, link).
Message #46 received at 22883@debbugs.gnu.org (full text, mbox, reply):
On Fri, Jun 03, 2016 at 06:12:47PM +0200, Ludovic Courtès wrote: > Hello! > > So we sign Git commits, and now we want to authenticate Git checkouts. > There’s a series of bad news. > > First, ‘git pull’ doesn’t do it for you, you have to pass ‘--verify’ and > there’s no way to set it globally. Since Git already has the git-verify-commit tool, I bet we could convince the Git project to implement this as a repo configuration option. Even better if we brought a patch :) > Second, even if it did, it would be a shallow check: as Mike notes in > <https://mikegerwitz.com/papers/git-horror-story> 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. That doesn't sound so bad. > 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. IOW, we want to know whether the key used to sign > the commit is among the authorized developer keys. So, we need some sort of Guix keyring system, right? We'd have to verify that a signature was made with an authorized key, and then validate the signature itself? Now it's getting complicated... > 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. > > Fifth, even if we did that, we’d be stuck parsing the possibly l10n’d > output of ‘gpg’. Pretty fragile. According to the man pages gpg(1) and gpg2(1), the value "1" is returned if a signature check fails, and there are "other error codes for fatal errors". If these return values are consistent across GPG versions, maybe they provide enough information for us. Return values are a lot easier to parse than stdout / stderr, in my experience. If we want to go down this path, we should figure out what we'd want to do with GPG besides `gpg --verify`. > Sixth, OK, we’ll use libgit2, and write Guile bindings, maybe based on > the CHICKEN bindings², easy! Well no, it turns out that libgit2³ has no > support for signed commits (the ‘signature’ abstraction there has > nothing to do with OpenPGP signatures.) That's too bad.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 04 Jun 2016 04:27:02 GMT) (full text, mbox, link).
Message #49 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Ludo: 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. > Second, even if it did, it would be a shallow check: as Mike notes in > <https://mikegerwitz.com/papers/git-horror-story> 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. > 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. > 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? Or are you just considering the possibility? I agree that it is awkward. At the same time, making it configurable (in the git sense) can potentially be very dangerous, because a malicious script (e.g. configure) could just modify it to a noop (e.g. `true`) and circumvent signature checks. > Fifth, even if we did that, we’d be stuck parsing the possibly l10n’d > output of ‘gpg’. Pretty fragile. In the log output? You could use --pretty and %G*. Otherwise, yes parsing GPG's output seems dangerous; surely there's a better way (like Leo mentioned). > Well no, it turns out that libgit2³ has no support for signed commits > (the ‘signature’ abstraction there has nothing to do with OpenPGP > signatures.) !? D: That's more concerning from a community mindset standpoint than anything. > 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 stumbled upon git-lockup⁴, which uses something other than OpenPGP to > sign objects in Git. However, signatures are not stored in commits but > rather in “git notes”, which, IIUC, are mutable objects detached from > the rest of the object store, so not great. It seems a bit over-complicated. Without reading much into it, it doesn't strike me as much different than a detached signature, but the problem is that the signature (as you implied) can just be deleted. Git's commit/tag signatures are embedded in the actual object. git-lockup also seems to hash "(branch,commitid) pairs", which signs considerably less data than Git's signature would (unless it actually signs the full object, not a string referencing it). I'll have to read over your first reference (your message) and its references; now I'm curious. [*]: 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. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer https://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 04 Jun 2016 11:05:01 GMT) (full text, mbox, link).
Message #52 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Leo Famulari <leo@famulari.name> skribis: > On Fri, Jun 03, 2016 at 06:12:47PM +0200, Ludovic Courtès wrote: >> Hello! >> >> So we sign Git commits, and now we want to authenticate Git checkouts. >> There’s a series of bad news. >> >> First, ‘git pull’ doesn’t do it for you, you have to pass ‘--verify’ and >> there’s no way to set it globally. > > Since Git already has the git-verify-commit tool, I bet we could > convince the Git project to implement this as a repo configuration > option. Even better if we brought a patch :) Sure. :-) >> 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. IOW, we want to know whether the key used to sign >> the commit is among the authorized developer keys. > > So, we need some sort of Guix keyring system, right? We'd have to verify > that a signature was made with an authorized key, and then validate the > signature itself? Now it's getting complicated... Fundamentally, it’s very simple. It’s just that OpenPGP is not designed to do this, and GPG doesn’t help with such uses. >> 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. >> >> Fifth, even if we did that, we’d be stuck parsing the possibly l10n’d >> output of ‘gpg’. Pretty fragile. > > According to the man pages gpg(1) and gpg2(1), the value "1" is returned > if a signature check fails, and there are "other error codes for fatal > errors". If these return values are consistent across GPG versions, > maybe they provide enough information for us. The problem is the meaning of a “signature failure.” We need to distinguish between the cases that appear in ‘signature-case’: http://git.savannah.gnu.org/cgit/guix.git/tree/guix/pki.scm#n179 The ‘gpg’ command hardly helps with that, plus a signature is considered “valid” if it’s made by someone “trusted” in the sense of the WoT. Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 04 Jun 2016 11:19:02 GMT) (full text, mbox, link).
Message #55 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi! Mike Gerwitz <mtg@gnu.org> 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 >> <https://mikegerwitz.com/papers/git-horror-story> 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: <http://bzr.savannah.gnu.org/lh/gsrc/trunk/annotate/head:/gar.lib.mk#L217>.) >> 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’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 04 Jun 2016 16:22:01 GMT) (full text, mbox, link).
Message #58 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi,
Ludo' asked us to send some comments on how to verify git commits. I
only had time to quickly browse the mail thread.
I would indeed suggest to use gpgv (or gpgv2, but I hope Guix has alread
moved to name gpg2 gpg) because we once wrote it for Debian. It has the
simplest semantics and thus best fits your purpose. We use it in GnuPG
itself for the speedo build system; it is sufficent to run this simple
script:
--8<---------------cut here---------------start------------->8---
if ! $GPGV --keyring "$distsigkey" swdb.lst.sig swdb.lst; then
echo "list of software versions is not valid!" >&2
exit 1
fi
--8<---------------cut here---------------end--------------->8---
In all other context I would suggest the use of GPGME to verify
signatures, because GPGME also evaluates the trust and all the status
line gpg spits out.
There are no issues with l10n because _all_ scripts SHOULD use gpg with
the options --status-fd and --with-colons. That output creates a well
defined API and we try very hard never to break it.
Mike Gerwitz's article is a bit long read right now. I have never
looked into git to check whether git correctly calls gpg to verify
signatures. That should eventually be done. And yes, please sign your
commits (I use an Ed25519 key stored on a Gnuk token; which works very
well).
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 04 Jun 2016 16:25:01 GMT) (full text, mbox, link).
Message #61 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sat, Jun 04, 2016 at 13:17:53 +0200, Ludovic Courtès wrote: > 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 Oh, excellent; I'm not sure if I would have come across that. I should poke around Guix a bit more and see all the goodies that everyone has created. Thanks. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer https://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 04 Jun 2016 17:03:02 GMT) (full text, mbox, link).
Message #64 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On 2016-06-04(01:17:53+0200), Ludovic Courtès wrote: > Hi! > > Mike Gerwitz <mtg@gnu.org> 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 > >> <https://mikegerwitz.com/papers/git-horror-story> 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: > <http://bzr.savannah.gnu.org/lh/gsrc/trunk/annotate/head:/gar.lib.mk#L217>.) > > >> 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. -- ♥Ⓐ ng0 4096R/13212A27975AF07677A29F7002A296150C201823
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 04 Jun 2016 22:29:02 GMT) (full text, mbox, link).
Message #67 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi Werner, Werner Koch <wk@gnupg.org> skribis: > I would indeed suggest to use gpgv (or gpgv2, but I hope Guix has alread > moved to name gpg2 gpg) We have a policy to respect what upstream does because in general we cannot or shouldn’t try to guess what’s “best”, IMO. So in this case, we keep the default names, ‘gpg2’ and ‘gpgv2’. Do you think we should rename those files? > because we once wrote it for Debian. It has the simplest semantics > and thus best fits your purpose. We use it in GnuPG itself for the > speedo build system; it is sufficent to run this simple script: > > --8<---------------cut here---------------start------------->8--- > if ! $GPGV --keyring "$distsigkey" swdb.lst.sig swdb.lst; then > echo "list of software versions is not valid!" >&2 > exit 1 > fi > --8<---------------cut here---------------end--------------->8--- OK. The problem I mentioned is that git expects to invoke ‘gpg’, not ‘gpgv’, and it does not provide a way to pass a different argument list: https://github.com/git/git/blob/master/gpg-interface.c#L213 > In all other context I would suggest the use of GPGME to verify > signatures, because GPGME also evaluates the trust and all the status > line gpg spits out. > > There are no issues with l10n because _all_ scripts SHOULD use gpg with > the options --status-fd and --with-colons. That output creates a well > defined API and we try very hard never to break it. I’m aware of it, but unfortunately, git invokes gpg on the user’s behalf, and all it gives is the human-readable, l10n’d output: --8<---------------cut here---------------start------------->8--- $ LANGUAGE=fr_FR git log --pretty="format:%H %GG" HEAD |head -4 40d71e44f5068b28f48bd131940260cc0ab2e2d1 gpg: Signature faite le Sun 05 Jun 2016 12:05:39 AM CEST avec la clef RSA d'identifiant 3D9AEBB5 gpg: Bonne signature de « Ludovic Courtès <ludo@gnu.org> » [totale] gpg: alias « Ludovic Courtès <ludo@chbouib.org> » [totale] gpg: alias « Ludovic Courtès (Inria) <ludovic.courtes@inria.fr> » [totale] --8<---------------cut here---------------end--------------->8--- (Internally it does use ‘--status-fd’ but that doesn’t help us as users.) > Mike Gerwitz's article is a bit long read right now. I have never > looked into git to check whether git correctly calls gpg to verify > signatures. That should eventually be done. And yes, please sign your > commits (I use an Ed25519 key stored on a Gnuk token; which works very > well). We sign commits and it’s wonderful; now all we need is tools to actually use those signatures to authenticate checkouts. :-) Thanks for taking the time to comment! Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sun, 05 Jun 2016 01:45:02 GMT) (full text, mbox, link).
Message #70 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sat, Jun 04, 2016 at 18:19:31 +0200, Werner Koch wrote: > There are no issues with l10n because _all_ scripts SHOULD use gpg with > the options --status-fd and --with-colons. That output creates a well > defined API and we try very hard never to break it. > [...] > I have never looked into git to check whether git correctly calls gpg > to verify signatures. That should eventually be done. A quick glance (latest master, gpg-interface.c:208 verify_signed_buffer): It invokes `gpg --status-fd=1 --verify FILE -`, where FILE is a signature written to a temporary file for the sake of invoking GPG. It checks for a non-zero exit code and GOODSIG: ret |= !strstr(pbuf->buf, "\n[GNUPG:] GOODSIG "); -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer https://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sun, 05 Jun 2016 07:57:02 GMT) (full text, mbox, link).
Message #73 received at 22883@debbugs.gnu.org (full text, mbox, reply):
On Sun, 5 Jun 2016 00:27, ludo@gnu.org said:
> cannot or shouldn’t try to guess what’s “best”, IMO. So in this case,
> we keep the default names, ‘gpg2’ and ‘gpgv2’.
>
> Do you think we should rename those files?
Given that Guix is a new distro you should really try to get rid of 1.4
and only use 2.1. For Windows we use the name "gpg" for a long time now
and there is a configure option --enable-gpg2-is-gpg to make it easier.
> We sign commits and it’s wonderful; now all we need is tools to actually
> use those signatures to authenticate checkouts. :-)
Right - Although I sign my commits,e other GnuPG hackers don't do it,
and thus for me there is no strong need to verify the commits. But we
should have these tools.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sun, 05 Jun 2016 20:40:02 GMT) (full text, mbox, link).
Message #76 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Ludovic Courtès writes: >>> Second, even if it did, it would be a shallow check: as Mike notes in >>> <https://mikegerwitz.com/papers/git-horror-story> 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. One theoretical optimization: if I verify the DAG, could I store somewhere that I've verified from commit cabba6e and upward already, so the next time I verify it only has to verify the new commits? Mostly makes sense if we're already going down the only mildly crazypants direction of implementing our own tooling :) - Chris
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sun, 05 Jun 2016 21:16:01 GMT) (full text, mbox, link).
Message #79 received at 22883@debbugs.gnu.org (full text, mbox, reply):
On Sun, Jun 05, 2016 at 03:39:04PM -0500, Christopher Allan Webber wrote: > One theoretical optimization: if I verify the DAG, could I store > somewhere that I've verified from commit cabba6e and upward already, so > the next time I verify it only has to verify the new commits? AIUI `git verify-commit` takes a single commit as an argument, so you can pass it an argument like this: $ git verify-commit $(git rev-list deadbeef..cabba6e) ... and it will only look at those. So, you would tailor the range of commits that you want to verify. > Mostly makes sense if we're already going down the only mildly > crazypants direction of implementing our own tooling :) It seems you'd want a tool that you trust to store a reference to the latest commit you trust, and use it to create the range of commits you pass to `git rev-list`.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 06 Jun 2016 02:43:02 GMT) (full text, mbox, link).
Message #82 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sun, Jun 05, 2016 at 15:39:04 -0500, Christopher Allan Webber wrote:
> One theoretical optimization: if I verify the DAG, could I store
> somewhere that I've verified from commit cabba6e and upward already, so
> the next time I verify it only has to verify the new commits?
tbh, I haven't given this the amount of thought/research that I feel it
needs. Unfortunately, you got me thinking, so here's another long
message.
In essence, this is equivalent to Ludo's suggestion of stopping at
the last tag (if you envision, say, tagging the last processed commit)
_provided that_ you also verify the commit that the tag is pointing to.
My short answer is: practically speaking, it's probably fine, because
you're more than likely trying to defend against an attacker that gains
access to the repo, not a second-preimage attack.
* *
*
Long answer (braindump):
When I consider the potential threats, I consider that the integrity of
each blob, tree, commit, etc are fairly well assured by their hashes,
but depend entirely on the security of SHA-1, whose future is
increasingly grim. SHA-1 does just fine for uniquely identifying
objects---and if it didn't, hashes offending preimages would just be
blacklisted. But it was never intended for security.
The problem is pretty bad: signed commits will ensure the integrity of
the commit itself (the object---as in `git cat-file -p COMMIT`); the
problem is that you don't just have to find a preimage for the hashes
signed in that commit: the tree hash is what really dictates the
content, and that tree hash in turn identifies other trees and blobs:
$ git cat-file -p 'HEAD^{tree}'
...
100644 blob 9b9481deea8cee4cc61971a752d02c04d5f0654e configure.ac
040000 tree f2b4528e1f66f3bbc4742dc4a11bd1283cd475b9 doc
...
That blob contains the actual file contents.
So in a large project like Guix, you have so many opportunities! You
can try to find preimages for any of the trees or blobs _without having
to worry about any signatures_; neither trees nor blobs are signed.
With that said, if I recall correctly (and after a very brief glance at
fetch-pack.c), a successful preimage attack would only affect users who
haven't already fetched the legitimate object---otherwise Git wouldn't
bother fetching it. I'm not sure if I find comfort in this or not: it's
been used by some to dismiss the problem of collisions, but (assuming
git is silent about it---and why wouldn't it be, as it wouldn't know
better) that's worse, since maintainers and common contributors wouldn't
notice anything wrong at all. But someone who clones fresh and compiles
would be screwed.
So signing commits almost certainly protects you against someone who
gains access to the repository on a common origin or a
maintainer/contributor's PC, provided that nobody's private key is
compromised.
But there doesn't seem to be any way to secure a git repository against
a second-preimage attack.
So given that, it doesn't really matter if you re-verify all the commits
or not: an attacker doesn't need to even bother with the commit
object. I guess one option is to keep a local copy of the repository,
clone a fresh copy, and occasionally diff _every_ object (commit, tag,
tree, blob) for differences.
So if Git wants to take this issue seriously, changes have to be
made. In the meantime, in addition to commit verification, you can
always keep around a local copy of the repository, always clone a copy,
and ensure that builds between the two are reproducible.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 06 Jun 2016 07:03:01 GMT) (full text, mbox, link).
Message #85 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hello, Mike Gerwitz <mtg@gnu.org> skribis: > But there doesn't seem to be any way to secure a git repository against > a second-preimage attack. That’s by large beyond the scope of this discussion. :-) I think all we want is to allow someone who gets a checkout of Guix to authenticate the source code, i.e., to make sure it was committed by one of these awesome Guix hackers and not by Mr. Evildoer. Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 06 Jun 2016 15:33:01 GMT) (full text, mbox, link).
Message #88 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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 <mtg@gnu.org> 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 > > >> <https://mikegerwitz.com/papers/git-horror-story> 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: > > <http://bzr.savannah.gnu.org/lh/gsrc/trunk/annotate/head:/gar.lib.mk#L217>.) > > > > >> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 06 Jun 2016 21:02:01 GMT) (full text, mbox, link).
Message #91 received at 22883@debbugs.gnu.org (full text, mbox, reply):
On Sun, Jun 05, 2016 at 09:51:45AM +0200, Werner Koch wrote: > Given that Guix is a new distro you should really try to get rid of 1.4 > and only use 2.1. For Windows we use the name "gpg" for a long time now > and there is a configure option --enable-gpg2-is-gpg to make it easier. If a Guix user installs GnuPG without specifying the version, which I think is the typical behavior, they will get the latest version that we package (currently 2.1.12). That's not exactly what you are requesting, but it should steer some users towards the modern branch :) For your reference, we package the classic, stable, and modern branches.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 07 Jun 2016 08:10:02 GMT) (full text, mbox, link).
Message #94 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Leo Famulari <leo@famulari.name> skribis: > On Sun, Jun 05, 2016 at 09:51:45AM +0200, Werner Koch wrote: >> Given that Guix is a new distro you should really try to get rid of 1.4 >> and only use 2.1. For Windows we use the name "gpg" for a long time now >> and there is a configure option --enable-gpg2-is-gpg to make it easier. > > If a Guix user installs GnuPG without specifying the version, which I > think is the typical behavior, they will get the latest version that we > package (currently 2.1.12). That's not exactly what you are requesting, > but it should steer some users towards the modern branch :) > > For your reference, we package the classic, stable, and modern branches. Nevertheless, we could configure GPG 2.x with --enable-gpg2-is-gpg, if that’s what Werner recommends. Thanks, Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 07 Jun 2016 11:32:02 GMT) (full text, mbox, link).
Message #97 received at 22883@debbugs.gnu.org (full text, mbox, reply):
On Tue, 7 Jun 2016 10:08, ludo@gnu.org said:
> Nevertheless, we could configure GPG 2.x with --enable-gpg2-is-gpg, if
> that’s what Werner recommends.
It would help to avoid trouble in the future. Debian will also install
gpg2 as gpg and provide 1.4 only a non-mandatory package gnupg1.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 07 Jun 2016 15:34:03 GMT) (full text, mbox, link).
Message #100 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On 2016-06-07(01:25:44+0200), Werner Koch wrote: > On Tue, 7 Jun 2016 10:08, ludo@gnu.org said: > > > Nevertheless, we could configure GPG 2.x with --enable-gpg2-is-gpg, if > > that’s what Werner recommends. > > It would help to avoid trouble in the future. Debian will also install > gpg2 as gpg and provide 1.4 only a non-mandatory package gnupg1. > > > Shalom-Salam, > > Werner I can add Gentoo to the list of gpg2 -> gpg symlinking systems, though this is expected with 2.x version and GnuPG having this as quasi default: ~$ ls -al /usr/bin/gpg* lrwxrwxrwx 1 root root 4 May 20 13:45 /usr/bin/gpg -> gpg2 ....... lrwxrwxrwx 1 root root 5 May 20 13:45 /usr/bin/gpgv -> gpgv2 -- ♥Ⓐ ng0 For non-prism friendly talk find me on psyced.org / loupsycedyglgamf.onion
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 22 Jul 2016 08:23:02 GMT) (full text, mbox, link).
Message #103 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi!
ludo@gnu.org (Ludovic Courtès) skribis:
> Sixth, OK, we’ll use libgit2, and write Guile bindings, maybe based on
> the CHICKEN bindings², easy! Well no, it turns out that libgit2³ has no
> support for signed commits (the ‘signature’ abstraction there has
> nothing to do with OpenPGP signatures.)
>
> 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?)?!
This bit was too pessimistic it seems. :-)
With the quick-hack libgit2 bindings attached, I can run this program,
which authenticates HEAD:
--8<---------------cut here---------------start------------->8---
(use-modules (guix git)
(guix gnupg)
(srfi srfi-11)
(srfi srfi-26))
(let* ((repo (open-repository "."))
(head (repository-head repo))
(commit-id (reference-target head)))
(let-values (((signature signed-data)
(commit-signature repo commit-id)))
(with-fluids ((%default-port-encoding "UTF-8"))
(call-with-output-file "/tmp/s"
(cut display signature <>))
(call-with-output-file "/tmp/d"
(cut display signed-data <>)))
(pk (gnupg-verify "/tmp/s" "/tmp/d"))))
--8<---------------cut here---------------end--------------->8---
… which gives:
--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guile t.scm
gpg: Signature made Thu 21 Jul 2016 06:53:27 PM CEST using RSA key ID 3D9AEBB5
gpg: Good signature from "Ludovic Courtès <ludo@gnu.org>" [full]
gpg: aka "Ludovic Courtès <ludo@chbouib.org>" [full]
gpg: aka "Ludovic Courtès (Inria) <ludovic.courtes@inria.fr>" [full]
;;; (((unparsed-line "[GNUPG:] NEWSIG") (signature-id "5U2RqMgQpDFefFuBzsYBDsrL9xg" "2016-07-21" 1469120007) (good-signature "090B11993D9AEBB5" "Ludovic Courtès <ludo@gnu.org>") (valid-signature "3CE464558A84FDC69DB40CFB090B11993D9AEBB5" "2016-07-21" 1469120007) (unparsed-line "[GNUPG:] TRUST_FULLY")))
--8<---------------cut here---------------end--------------->8---
So I think we can go from here. Our repo would contain a Scheme list of
authorized OpenPGP fingerprints, and we’d check whether the fingerprint
that shows up in ‘valid-signature’ above is among them (IMO this is
better than using a GnuPG keyring because GnuPG keyrings are opaque
binary blobs—we wouldn’t be able to diff subsequent revisions of the
keyring—and they contain full OpenPGP keys, including signature packets
and all that, which we don’t need/want for authorization purposes; we
may still want to store a keyring though, but simply for the purposes of
allowing gpg to check signatures.)
Since we just need to read Git objects, after all, another option would
be to avoid libgit2 and read them ourselves, which wouldn’t be hard (I’d
expect ~500 lines of code), would avoid the dependency, and be more
robust (no C!).
However, ‘guix pull’ can make good use of libgit2 to directly clone/pull
in the future, so it makes sense to have libgit2 bindings.
It Would Be Nice if the libgit2 bindings were maintained separately. We
can start with just the features we need as (guix git), but if anyone
wants to “externalize” it and improve it, that would be more than
welcome!
Thoughts?
Thanks,
Ludo’.
[git.scm (text/plain, inline)]
;;; Copyright © Ludovic Courtès <ludo@gnu.org>
;;; Released under the GNU GPL version 3 or later.
(define-module (guix git)
#:use-module (rnrs bytevectors)
#:use-module (system foreign)
#:use-module (ice-9 match)
#:export (repository?
open-repository
reference?
repository-head
reference-target
oid?
commit-signature))
;; DRAFT!
(define libgit2
(dynamic-link "/gnu/store/g8r0qwnzf2j17hd84cchc6cmr51sflz8-libgit2-0.24.1/lib/libgit2"))
(define (libgit2->procedure return name params)
(pointer->procedure return (dynamic-func name libgit2) params))
(define-inlinable (libgit2->procedure* name params)
(let ((proc (libgit2->procedure int name params)))
(lambda args
(let ((ret (apply proc args)))
(unless (zero? ret)
(throw 'git-error ret))))))
(define initialize!
(libgit2->procedure int "git_libgit2_init" '()))
(define-syntax define-libgit2-type
(lambda (s)
"Define a wrapped pointer type for an opaque type of libgit2."
(syntax-case s ()
((_ name)
(let ((symbol (syntax->datum #'name))
(identifier (lambda (symbol)
(datum->syntax #'name symbol))))
(with-syntax ((rtd (identifier (symbol-append '< symbol '>)))
(pred (identifier (symbol-append symbol '?)))
(wrap (identifier (symbol-append 'pointer-> symbol)))
(unwrap (identifier (symbol-append symbol '->pointer))))
#`(define-wrapped-pointer-type rtd
pred
wrap unwrap
(lambda (obj port)
(format port "#<git-~a ~a>"
#,(symbol->string symbol)
(number->string (pointer-address (unwrap obj))
16))))))))))
(define-libgit2-type repository)
(define open-repository
(let ((proc (libgit2->procedure* "git_repository_open" '(* *))))
(lambda (file)
(let ((result (bytevector->pointer (make-bytevector (sizeof '*)))))
(proc result (string->pointer file))
(pointer->repository (dereference-pointer result))))))
(define-libgit2-type reference)
(define repository-head
(let ((proc (libgit2->procedure* "git_repository_head" '(* *))))
(lambda (repository)
(let ((result (bytevector->pointer (make-bytevector (sizeof '*)))))
(proc result (repository->pointer repository))
(pointer->reference (dereference-pointer result))))))
(define-libgit2-type oid)
(define reference-target
(let ((proc (libgit2->procedure '* "git_reference_target" '(*))))
(lambda (reference)
(pointer->oid (proc (reference->pointer reference))))))
(define-libgit2-type commit)
(define lookup-commit
(let ((proc (libgit2->procedure* "git_commit_lookup" `(* * *))))
(lambda (repository oid)
(let ((result (bytevector->pointer (make-bytevector (sizeof '*)))))
(proc result (repository->pointer repository) (oid->pointer oid))
(pointer->commit (dereference-pointer result))))))
(define commit-raw-header
(let ((proc (libgit2->procedure '* "git_commit_raw_header" '(*))))
(lambda (commit)
(pointer->string (proc (commit->pointer commit))))))
(define %buffer-struct ;git_buf
(list '* size_t size_t))
(define free-buffer
(libgit2->procedure void "git_buf_free" '(*)))
(define (buffer-content buf)
(match (parse-c-struct buf %buffer-struct)
((pointer asize size)
(pointer->bytevector pointer size))))
(define (buffer-content/string buf)
(match (parse-c-struct buf %buffer-struct)
((pointer asize size)
(pointer->string pointer size "UTF-8"))))
(define commit-signature
(let ((proc (libgit2->procedure* "git_commit_extract_signature"
'(* * * * *))))
(lambda* (repository oid #:optional (field "gpgsig"))
(let ((signature (make-c-struct %buffer-struct
`(,%null-pointer 0 0)))
(data (make-c-struct %buffer-struct
`(,%null-pointer 0 0))))
(proc signature data (repository->pointer repository)
(oid->pointer oid)
(string->pointer field))
(let ((signature* (buffer-content/string signature))
(data* (buffer-content/string data)))
(free-buffer signature)
(free-buffer data)
(values signature* data*))))))
(define-libgit2-type object)
(define GIT_OBJ_ANY -2)
(define lookup-object
(let ((proc (libgit2->procedure* "git_object_lookup" `(* * * ,int))))
(lambda* (repository oid #:optional (type GIT_OBJ_ANY))
(let ((result (bytevector->pointer (make-bytevector (sizeof '*)))))
(proc result (repository->pointer repository) (oid->pointer oid)
type)
(pointer->object (dereference-pointer result))))))
(initialize!)
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 22 Jul 2016 12:59:02 GMT) (full text, mbox, link).
Message #106 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi Ludo, This is some awesome work! On Fri, Jul 22, 2016 at 4:22 AM, Ludovic Courtès <ludo@gnu.org> wrote: > It Would Be Nice if the libgit2 bindings were maintained separately. We > can start with just the features we need as (guix git), but if anyone > wants to “externalize” it and improve it, that would be more than > welcome! I started a "guile-git" project awhile ago, but didn't get anywhere. Maybe I can snarf your bindings as a starting point? If the bindings were an external project, would it be an optional or mandatory dependency? Would you be OK with licensing the code under LGPLv3 or later? Thanks! - Dave
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 22 Jul 2016 13:59:02 GMT) (full text, mbox, link).
Message #109 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hello! "Thompson, David" <dthompson2@worcester.edu> skribis: > On Fri, Jul 22, 2016 at 4:22 AM, Ludovic Courtès <ludo@gnu.org> wrote: > >> It Would Be Nice if the libgit2 bindings were maintained separately. We >> can start with just the features we need as (guix git), but if anyone >> wants to “externalize” it and improve it, that would be more than >> welcome! > > I started a "guile-git" project awhile ago, but didn't get anywhere. > Maybe I can snarf your bindings as a starting point? Definitely, that’d be a great contribution! Among other things, I didn’t pay attention to memory management; some objects need finalizers, some are documented as having the same life time as the repository object they come from (a weak-key hash table could be used to have the life time of Scheme object match that of their C counterpart.) Nothing terrible though, and you know all that very well. > If the bindings were an external project, would it be an optional or > mandatory dependency? It may become a mandatory dependency because we’d use it in ‘guix pull’. > Would you be OK with licensing the code under LGPLv3 or later? Fine with me! Thank you! Ludo’.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 25 Jul 2016 02:41:02 GMT) (full text, mbox, link).
Message #112 received at 22883@debbugs.gnu.org (full text, mbox, reply):
URL:
<http://savannah.gnu.org/support/?109104>
Summary: Add Git 'update' hook for Guix repositories
Project: Savannah Administration
Submitted by: civodul
Submitted on: Mon 25 Jul 2016 12:09:45 AM CEST
Category: Source code repositories - developer access
Priority: 5 - Normal
Severity: 3 - Normal
Status: None
Assigned to: None
Originator Email: ludo@gnu.org
Operating System: None
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Details:
Hello,
Could you add the attach file as an 'update' hook for all the Guix
repositories?
Thanks in advance,
Ludo'.
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Mon 25 Jul 2016 12:09:45 AM CEST Name: assert-commit-signed Size: 764B
By: civodul
Git 'update' hook to reject unsigned commits
<http://savannah.gnu.org/support/download.php?file_id=38011>
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/support/?109104>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 25 Jul 2016 02:41:03 GMT) (full text, mbox, link).
Message #115 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Update of sr #109104 (project administration):
Status: None => In Progress
Assigned to: None => rwp
_______________________________________________________
Follow-up Comment #1:
Sure thing. I will add it to this list.
guix.git
guix/dhcp.git
guix/gnunet.git
guix/guix-artwork.git
guix/maintenance.git
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/support/?109104>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 25 Jul 2016 02:41:03 GMT) (full text, mbox, link).
Message #118 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Update of sr #109104 (project administration):
Status: In Progress => Done
Open/Closed: Open => Closed
_______________________________________________________
Follow-up Comment #2:
Done. Commits to those repositories will be required to be gpg signed now. Let
us know if you need anything else.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/support/?109104>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 25 Jul 2016 17:33:03 GMT) (full text, mbox, link).
Message #121 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Follow-up Comment #3, sr #109104 (project administration):
That was fast, thanks a lot, Bob!
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/support/?109104>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Added tag(s) security.
Request was from ludo@gnu.org (Ludovic Courtès)
to control@debbugs.gnu.org.
(Tue, 02 Aug 2016 22:16:02 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sun, 07 Aug 2016 06:08:03 GMT) (full text, mbox, link).
Message #126 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Follow-up Comment #4, sr #109104 (project administration):
Unfortunately, this hook can be easily defeated. Here's some example output
from the current tip of master:
$ git cat-file -p HEAD
tree c65e675351fe76b2630df24eddcb2449774eb344
parent e87c7ec2de815f05d7a84e2792e2da700bb26a38
author Leo Famulari <leo@famulari.name> 1470169005 -0400
committer Leo Famulari <leo@famulari.name> 1470538536 -0400
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXpqMoAAoJECZG+jC6yn8Ihn8P+wfUhS5HOL7181KC8ZRdTFC5
5XjavRq/08LJzO2mxer1r5oVcWYuZAvnPKZltO1vdIp0ncvU40c4nmaNpQiB/w6B
8slSkqBsoCVE7GEKHoAWju7Rwwlqw4fUSgDWw5JpJ/3S2PhRj+tvy8o/wCeBEwTL
c90yivRmpKZcdcRgSPHqhHhMJ7lIJxbvHKlb30SPz9vdQTj13EUeeyyJQc/7lu7D
kUiUu9MOjC3o8dPE8E7otMnD51xfj8SNvs5h7cZAMByS0Qk06RwK+O5POkBlXUMV
lVxgPJsC7LfqJJ/VGLb5uOIoXMUCGV3mzdDXA+Pe+xvTTGOT+8rNsPl7kwxAGYqC
vPVrY1dC6CzRX8/7etvb99UHf2nx0NbYRAvetZzh9j6WBbMqGBgHMndRh6i6Y7Fl
BioG+J22sXCQjf3ydRvjd8cznlfvBCTqo9zSqeoG7Ha/qSh1pX16KAUxLi1YGzK6
I79iqOEvpoxwS/9Ym+GB+4rLTimqhtDKN7v3XaQudJ8t6hMlGi+pqjiLhNI8q2c9
dd3RthLu+Zom4duwnGo0BJEVC+CDLYGcdiwCKOpLaI9KtQbCv6useALPBk5RKPHr
pE1Y7nTmBw7Rxl2GuaNOH9x5cHOuULfWW+HLm3JSwTjD4cpAxnFDP7qYINSo7XGR
HGWK/43B5syf6FhZws8N
=h+H0
-----END PGP SIGNATURE-----
gnu: Add python-pythondialog.
* gnu/packages/python.scm (python-pythondialog): New variable.
(python2-pythondialog): Inherit from PYTHON-PYTHONDIALOG.
Co-authored-by: Vincent Legoll <vincent.legoll@idgrilles.fr>
The hook currently greps for `^gpgsig '. It will indeed find a GPG signature
if it exists, but to circumvent it, an attacker need only put `gpgsig' in the
commit message at column 0---the commit messages aren't indented in the
output.
You can replace the entire loop in the hook with this:
git log --pretty='%GK %h %s' "$rev_old^..$rev_new" \
| awk '/^ / {
e=1
print "error: missing signature:" $0 > "/dev/stderr"
}
END { exit e }'
If the commit is not signed, then `%GK` (GPG key id) will yield an empty
string.
Here's some example output (run with HEAD~15..):
error: missing signature: 7ccb874 gnu: zsh: Move to shells.scm.
error: missing signature: 7977d76 Update NEWS.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/support/?109104>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Wed, 17 Aug 2016 15:35:03 GMT) (full text, mbox, link).
Message #129 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Follow-up Comment #5, sr #109104 (project administration):
Hi Mike,
The hook is indeed super naive. The goal was just to avoid _accidental_
pushes of unsigned commits, under the assumption that those with commit access
are well-behaved. :-)
But yeah, the goal is to ultimately scan the Git history and ensure only
authorized keys are used:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#103 .
Thanks,
Ludo'.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/support/?109104>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 24 Oct 2017 23:31:01 GMT) (full text, mbox, link).
Message #132 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hello,
Just a note for later…
ludo@gnu.org (Ludovic Courtès) skribis:
> With the quick-hack libgit2 bindings attached, I can run this program,
> which authenticates HEAD:
[...]
> So I think we can go from here. Our repo would contain a Scheme list of
> authorized OpenPGP fingerprints, and we’d check whether the fingerprint
> that shows up in ‘valid-signature’ above is among them
Storing the list of authorized keys in a file in the repo is
inconvenient: simply to retrieve it, you’d need to make a checkout. So
for each commit we verify, we have to check out the whole repo, which is
inefficient.
While reading
<http://karl.kornel.us/2017/10/welp-there-go-my-git-signatures/>, I
realized we could store in empty Git commit messages, which would
address the above problem (we could use a custom object type too, but
that would be less convenient.)
So the special commit could look like:
Authorization
(commit-authorizations
(authorization-commit (KEY1 KEY2 …))
(files ("hydra.gnu.org.pub") (KEY1 KEY2 …))
(files _ (KEY1 KEY2 …))) ;all other files
That way, to authenticate a commit, we first fetch the latest
authorization commit, read the authorization rules from there, and make
sure that the changes it makes match the rules.
Thoughts?
Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 28 Aug 2018 19:57:01 GMT) (full text, mbox, link).
Message #135 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
This isn't exactly pretty, and obviously a better long-term solution is
needed, but I wrote a quick shell script to at least partially addresses
some my biggest fears with guix pull...
Basically, it updates a git checkout, checks the signatures on the
commits, looking for the topmost signed commit by a key in a specific
keyring, and then runs guix pull with that commit.
It relies on a custom gpg directory and assumes any of the keys in the
keyring are valid potential signers of the commits; the web of trust is
essentially ignored.
I really don't like having a custom GNUPGHOME, but I didn't see any
other obvious way to pass arguments to git to use a custom keyring. I
populated this GNUPGHOME with keys from:
https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix&download=1
And then ran gpg --refresh-keys on it, as several keys were
outdated/expired.
(an alternative approach to populate the keyring might be:
https://gitlab.com/Efraim/guix-keyring)
It also assumes a git checkout where "git pull" pulls from the correct
repository.
It assumes guix --version returns a valid git hash, so would require
some more tweaks to get it working from a fresh guix install.
All those caveats aside, it seems to work well enough for me, and
writing this email took longer than writing the script. :)
live well,
vagrant
#!/bin/sh
set -x
set -e
workdir=/home/vagrant/src/guix
export GNUPGHOME=$workdir/verified-pull/gnupg
cd $workdir
git pull
guixversion=$(guix --version | awk '/^guix/{print $4}')
commits=$(git log ${guixversion}.. --pretty='format:%G?,%H')
# · %G?: show
# "G" for a good (valid) signature,
# "B" for a bad · %signature,
# "U" for a good signature with unknown validity,
# "X" for a good · %signature that has expired,
# "Y" for a good signature made by an expired · %key,
# "R" for a good signature made by a revoked key,
# "E" if the · %signature cannot be checked (e.g. missing key) and
# "N" for no signature
for commitlog in $commits ; do
commitverify=$(echo $commitlog | cut -d , -f 1)
commit=$(echo $commitlog | cut -d , -f 2)
case $commitverify in
G|U) git verify-commit $commit && \
guix pull --url=file://$workdir --commit=$commit && \
exit 0 ;;
esac
done
echo unable to find signed commit
exit 1
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sun, 02 Sep 2018 16:06:01 GMT) (full text, mbox, link).
Message #138 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi Vagrant, Vagrant Cascadian <vagrant@debian.org> skribis: > This isn't exactly pretty, and obviously a better long-term solution is > needed, but I wrote a quick shell script to at least partially addresses > some my biggest fears with guix pull... > > Basically, it updates a git checkout, checks the signatures on the > commits, looking for the topmost signed commit by a key in a specific > keyring, and then runs guix pull with that commit. Thanks for sharing! Even if it’s not the long-term solution, it’s a useful way to see how to move forward. > It relies on a custom gpg directory and assumes any of the keys in the > keyring are valid potential signers of the commits; the web of trust is > essentially ignored. > > I really don't like having a custom GNUPGHOME, but I didn't see any > other obvious way to pass arguments to git to use a custom keyring. I > populated this GNUPGHOME with keys from: > > https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix&download=1 > > And then ran gpg --refresh-keys on it, as several keys were > outdated/expired. ‘gpgv’, which is recommended for this use case, has a ‘--keyring’ argument. I suppose we could use that. > (an alternative approach to populate the keyring might be: > https://gitlab.com/Efraim/guix-keyring) Indeed, didn’t know about this repo. Thank you, Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sun, 02 Sep 2018 17:16:01 GMT) (full text, mbox, link).
Message #141 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On 2018-09-02, Ludovic Courtès wrote: > Vagrant Cascadian <vagrant@debian.org> skribis: >> I really don't like having a custom GNUPGHOME, but I didn't see any >> other obvious way to pass arguments to git to use a custom keyring. I >> populated this GNUPGHOME with keys from: >> >> https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix&download=1 >> >> And then ran gpg --refresh-keys on it, as several keys were >> outdated/expired. > > ‘gpgv’, which is recommended for this use case, has a ‘--keyring’ > argument. I suppose we could use that. I'm not sure how to get git to use gpgv instead of gpg, and extracting the information out of git and then implementing some external verification process, while possible, is likely error-prone. A feature request to git to allow passing gpg arguments or use gpgv would be the best way forward in the long-term. live well, vagrant
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sun, 02 Sep 2018 20:08:02 GMT) (full text, mbox, link).
Message #144 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Vagrant Cascadian <vagrant@debian.org> skribis: > On 2018-09-02, Ludovic Courtès wrote: >> Vagrant Cascadian <vagrant@debian.org> skribis: >>> I really don't like having a custom GNUPGHOME, but I didn't see any >>> other obvious way to pass arguments to git to use a custom keyring. I >>> populated this GNUPGHOME with keys from: >>> >>> https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix&download=1 >>> >>> And then ran gpg --refresh-keys on it, as several keys were >>> outdated/expired. >> >> ‘gpgv’, which is recommended for this use case, has a ‘--keyring’ >> argument. I suppose we could use that. > > I'm not sure how to get git to use gpgv instead of gpg, and extracting > the information out of git and then implementing some external > verification process, while possible, is likely error-prone. Oh right, IIRC Git cannot use gpgv (this was probably discussed in this issue, now that I think about it.) Good thing is that using Guile-Git as in the toy example at <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#103>, we can use gpgv. > A feature request to git to allow passing gpg arguments or use gpgv > would be the best way forward in the long-term. That would work too. Thanks, Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 20 Dec 2019 22:12:01 GMT) (full text, mbox, link).
Message #147 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hello Guix!
It’s high time for us to provide a means to authenticate Git checkouts.
It’s not clear what the perfect solution will be, so in the meantime I
think we need to have reasonable milestones that incrementally improve
the situation.
To begin with, I propose the attached script: when given a commit range,
it authenticates each commit, meaning that it ensures commits have a
valid signature and that that signature was made by one of the
authorized keys. Sample session:
--8<---------------cut here---------------start------------->8---
$ time ./pre-inst-env guile -e git-authenticate build-aux/git-authenticate.scm d68de958b60426798ed62797ff7c96c327a672ac 099ce5d4901706dc2c5be888a5c8cbf8fcd0d576
Authenticating d68de95 to 099ce5d (7938 commits)...
Signing statistics:
BCA689B636553801C3C62150197A5888235FACAC 1454
3CE464558A84FDC69DB40CFB090B11993D9AEBB5 1025
BBB02DDF2CEAF6A80D1DE643A2A06DF2A33A54FA 941
[...]
real 2m21.272s
user 1m38.741s
sys 0m59.546s
--8<---------------cut here---------------end--------------->8---
Limitations:
1. People (developers) have to run it manually, there’s no suitable
Git hook; ‘guix pull’ doesn’t run it.
2. The list of authorized keys is hard-coded.
3. It’s relatively slow (but faster than a shell script).
4. It lazily populates a keyring (under
~/.config/guix/keyrings/channels/guix.kbx) by fetching keys from
key servers, which may or may not have the keys.
5. It doesn’t address roll-back attacks and other attacks described in
<https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias>.
6. It doesn’t memorize which commits have already been verified.
7. I haven’t checked whether the hard-coded ‘%committers’ lists works
for commits before v1.0.1—help welcome!
It should be possible to address #2 by adding the list in the repo
itself, though we’d need to check the cost of accessing that list at
every commit.
#3 can probably be addressed by using a Scheme implementation of the
OpenPGP bits we need, such as that of Industria.
#4 can be addressed by storing the keys in the repo itself, either as
files directly or with a trick like
<https://365git.tumblr.com/post/2813251228/adding-a-gpg-public-key-to-a-repository>.
#6 could be addressed by storing Git notes maybe.
#5 is hard IMO, but it’s one of the things we discussed at the R-B
summit, so there’s hope.
I’d like to commit this script under build-aux/ as a first step.
Thoughts?
Thanks,
Ludo’.
PS: See <https://issues.guix.gnu.org/issue/22883> for context.
[git-authenticate.scm (text/plain, inline)]
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2019 Ludovic Courtès <ludo@gnu.org>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
;;;
;;; Authenticate a range of commits.
;;;
(use-modules (git)
(guix git)
(guix gnupg)
(guix utils)
(guix i18n)
(guix progress)
(srfi srfi-1)
(srfi srfi-11)
(srfi srfi-26)
(srfi srfi-34)
(srfi srfi-35)
(ice-9 match)
(ice-9 format)
(ice-9 vlist))
(define %committers
;; List of committers. These are the user names found on
;; <https://savannah.gnu.org/project/memberlist.php?group=guix> along with
;; the fingerprint of the signing (sub)key.
;;
;; TODO: Replace this statically-defined list by an in-repo list.
'(("andreas"
"AD17 A21E F8AE D8F1 CC02 DBD9 F7D5 C9BF 765C 61E3")
("ajgrf"
"2A39 3FFF 68F4 EF7A 3D29 12AF 6F51 20A0 22FB B2D5")
("alexvong1995"
"306F CB8F 2C01 C25D 29D3 0556 61EF 502E F602 52F2")
("alezost"
"4FB9 9F49 2B12 A365 7997 E664 8246 0C08 2A0E E98F")
("ambrevar"
"50F3 3E2E 5B0C 3D90 0424 ABE8 9BDC F497 A4BB CC7F")
("apteryx"
"27D5 86A4 F890 0854 329F F09F 1260 E464 82E6 3562")
("arunisaac"
"7F73 0343 F2F0 9F3C 77BF 79D3 2E25 EE8B 6180 2BB3")
("atheia"
"3B12 9196 AE30 0C3C 0E90 A26F A715 5567 3271 9948")
("bavier"
;; primary: "34FF 38BC D151 25A6 E340 A0B5 3453 2F9F AFCA 8B8E"
"A0C5 E352 2EF8 EF5C 64CD B7F0 FD73 CAC7 19D3 2566")
("beffa"
"3774 8024 880F D3FF DCA2 C9AB 5893 6E0E 2F1B 5A4C")
("benwoodcroft"
"BCF8 F737 2CED 080A 67EB 592D 2A6A D9F4 AAC2 0DF6")
("biscuolo"
"45CC 63B8 5258 C9D5 5F34 B239 D37D 0EA7 CECC 3912")
("boskovits"
"7988 3B9F 7D6A 4DBF 3719 0367 2506 A96C CF63 0B21")
("brettgilio"
"DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE")
("carl"
;; primary: "0401 7A2A 6D9A 0CCD C81D 8EC2 96AB 007F 1A7E D999"
"09CD D25B 5244 A376 78F6 EEA8 0CC5 2153 1979 91A5")
("cbaines"
"3E89 EEE7 458E 720D 9754 E0B2 5E28 A33B 0B84 F577")
("civodul"
"3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5")
("cwebber"
"510A 8628 E2A7 7678 8F8C 709C 4BC0 2592 5FF8 F4D3")
("dannym"
;; primary: "295A F991 6F46 F8A1 34B0 29DA 8086 3842 F0FE D83B"
"76CE C6B1 7274 B465 C02D B3D9 E71A 3554 2C30 BAA5")
("davexunit"
"B3C0 DB4D AD73 BA5D 285E 19AE 5143 0234 CEFD 87C3")
("davexunit (2nd)" ;FIXME: to be confirmed!
"8CCB A7F5 52B9 CBEA E1FB 2915 8328 C747 0FF1 D807")
("dvc"
"6909 6DFD D702 8BED ACC5 884B C5E0 51C7 9C0B ECDB")
("dvc (old)"
"5F43 B681 0437 2F4B A898 A64B 33B9 E9FD E28D 2C23")
("efraim"
"A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351")
("efraim (old)"
"9157 41FE B22F A4E3 3B6E 8F8D F4C1 D391 7EAC EE93")
("hoebjo"
"2219 43F4 9E9F 276F 9499 3382 BF28 6CB6 593E 5FFD")
("htgoebel"
"B943 509D 633E 80DD 27FC 4EED 634A 8DFF D3F6 31DF")
("ipetkov"
"7440 26BA 7CA3 C668 E940 1D53 0B43 1E98 3705 6942")
("iyzsong"
;; primary: "66A5 6D9C 9A98 BE7F 719A B401 2652 5665 AE72 7D37"
"0325 78A6 8298 94E7 2AA2 66F5 D415 BF25 3B51 5976")
;; https://lists.gnu.org/archive/html/guix-devel/2018-04/msg00229.html
("janneke (old)"
"DB34 CB51 D25C 9408 156F CDD6 A12F 8797 8D70 1B99")
("janneke"
"1A85 8392 E331 EAFD B8C2 7FFB F3C1 A0D9 C1D6 5273")
("jlicht"
;; primary: "1BA4 08C5 8BF2 0EA7 3179 635A 865D C0A3 DED9 B5D0"
"E31D 9DDE EBA5 4A14 8A20 4550 DA45 97F9 47B4 1025")
("jmd"
"8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3")
("kkebreau"
"83B6 703A DCCA 3B69 4BCE 2DA6 E6A5 EE3C 1946 7A0D")
("leungbk"
"45E5 75FA 53EA 8BD6 1BCE 0B4E 3ADC 75F0 13D6 78F9")
("lfam"
;; primary: "4F71 6F9A 8FA2 C80E F1B5 E1BA 5E35 F231 DE1A C5E0"
"B051 5948 F1E7 D3C1 B980 38A0 2646 FA30 BACA 7F08")
("lsl88"
"2AE3 1395 932B E642 FC0E D99C 9BED 6EDA 32E5 B0BC")
("marusich"
"CBF5 9755 CBE7 E7EF EF18 3FB1 DD40 9A15 D822 469D")
("mbakke"
"BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")
("mhw"
"D919 0965 CE03 199E AF28 B3BE 7CEF 2984 7562 C516")
("mothacehe"
"4008 6A7E 0252 9B60 31FB 8607 8354 7635 3176 9CA6")
("mthl"
"F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37")
("nckx"
;; primary: "F5BC 5534 C36F 0087 B39D 36EF 1C9D C4FE B9DB 7C4B"
"7E8F AED0 0944 78EF 72E6 4D16 D889 B0F0 18C5 493C")
("nckx (2nd)"
;; primary: "F5BC 5534 C36F 0087 B39D 36EF 1C9D C4FE B9DB 7C4B"
"F5DA 2032 4B87 3D0B 7A38 7672 0DB0 FF88 4F55 6D79")
("ngz"
"ED0E F1C8 E126 BA83 1B48 5FE9 DA00 B4F0 48E9 2F2D")
("pelzflorian"
"CEF4 CB91 4856 BA38 0A20 A7E2 3008 88CB 39C6 3817")
("pgarlick"
;; primary: "B68B DF22 73F9 DA0E 63C1 8A32 515B F416 9242 D600"
"C699 ED09 E51B CE89 FD1D A078 AAC7 E891 896B 568A")
("phant0mas"
"3A86 380E 58A8 B942 8D39 60E1 327C 1EF3 8DF5 4C32")
("reepca"
"74D6 A930 F44B 9B84 9EA5 5606 C166 AA49 5F7F 189C")
("rekado"
"BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC")
("rhelling"
"0154 E1B9 1CC9 D9EF 7764 8DE7 F3A7 27DB 44FC CA36")
("roelj"
"17CB 2812 EB63 3DFF 2C7F 0452 C3EC 1DCA 8430 72E1")
("roptat"
"B5FA E628 5B41 3728 B2A0 FAED 4311 1F45 2008 6A0C")
("samplet"
;; primary: "D6B0 C593 DA8C 5EDC A44C 7A58 C336 91F7 1188 B004"
"A02C 2D82 0EF4 B25B A6B5 1D90 2AC6 A5EC 1C35 7C59")
("sleep_walker"
"77DD AD2D 97F5 31BB C0F3 C7FD DFB5 EB09 AA62 5423")
("snape"
"F494 72F4 7A59 00D5 C235 F212 89F9 6D48 08F3 59C7")
("snape"
"F494 72F4 7A59 00D5 C235 F212 89F9 6D48 08F3 59C7")
("steap"
"4E26 CCE9 578E 0828 9855 BDD4 1C79 95D2 D5A3 8336")
("taylanub"
"9ADE 9ECF 2B19 C180 9C99 5CEA A1F4 CFCC 5283 6BAC")
;; https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00826.html
("thomasd"
"1DD1 681F E285 E07F 11DC 0C59 2E15 A6BC D77D 54FD")
("thomasd (old)"
"A5C5 92EA 606E 7106 A6A3 BC08 98B2 1575 91E1 2B08")
("toothbrush"
"D712 1D73 A40A 7264 9E43 ED7D F284 6B1A 0D32 C442")
("vagrantc"
"6580 7361 3BFC C5C7 E2E4 5D45 DC51 8FC8 7F97 16AA")
("wigust"
;; primary: "C955 CC5D C048 7FB1 7966 40A9 199A F6A3 67E9 4ABB"
"7238 7123 8EAC EB63 4548 5857 167F 8EA5 001A FA9C")
("wingo"
"FF47 8FB2 64DE 32EC 2967 25A3 DDC0 F535 8812 F8F2")))
(define %authorized-signing-keys
;; Fingerprint of authorized signing keys.
(map (match-lambda
((name fingerprint)
(string-filter char-set:graphic fingerprint)))
%committers))
(define %commits-with-bad-signature
;; Commits with a known-bad signature.
'("6a34f4ccc8a5d4a48e25ad3c9c512f8634928b91")) ;2016-12-29
(define %unsigned-commits
;; Commits lacking a signature.
'())
(define-syntax-rule (with-temporary-files file1 file2 exp ...)
(call-with-temporary-output-file
(lambda (file1 port1)
(call-with-temporary-output-file
(lambda (file2 port2)
exp ...)))))
(define (commit-signing-key repo commit-id)
"Return the OpenPGP key ID that signed COMMIT-ID (an OID). Raise an
exception if the commit is unsigned or has an invalid signature."
(let-values (((signature signed-data)
(catch 'git-error
(lambda ()
(commit-extract-signature repo commit-id))
(lambda _
(values #f #f)))))
(if (not signature)
(raise (condition
(&message
(message (format #f (G_ "commit ~a lacks a signature")
commit-id)))))
(begin
(with-fluids ((%default-port-encoding "UTF-8"))
(with-temporary-files data-file signature-file
(call-with-output-file data-file
(cut display signed-data <>))
(call-with-output-file signature-file
(cut display signature <>))
(let-values (((status data)
(with-error-to-port (%make-void-port "w")
(lambda ()
(gnupg-verify* signature-file data-file
#:key-download 'always)))))
(match status
('invalid-signature
;; There's a signature but it's invalid.
(raise (condition
(&message
(message (format #f (G_ "signature verification failed \
for commit ~a")
(oid->string commit-id)))))))
('missing-key
(raise (condition
(&message
(message (format #f (G_ "could not authenticate \
commit ~a: key ~a is missing")
(oid->string commit-id)
data))))))
('valid-signature
(match data
((fingerprint . user)
fingerprint)))))))))))
(define (authenticate-commit repository commit)
"Authenticate COMMIT from REPOSITORY and return the signing key fingerprint.
Raise an error when authentication fails."
(define id
(commit-id commit))
(define signing-key
(commit-signing-key repository id))
(unless (member signing-key %authorized-signing-keys)
(raise (condition
(&message
(message (format #f (G_ "commit ~a not signed by an authorized \
key: ~a")
(oid->string id) signing-key))))))
signing-key)
(define* (authenticate-commits repository commits
#:key (report-progress (const #t)))
"Authenticate COMMITS, a list of commit objects, calling REPORT-PROGRESS for
each of them. Return an alist showing the number of occurrences of each key."
(parameterize ((current-keyring (string-append (config-directory)
"/keyrings/channels/guix.kbx")))
(fold (lambda (commit stats)
(report-progress)
(let ((signer (authenticate-commit repository commit)))
(match (assoc signer stats)
(#f (cons `(,signer . 1) stats))
((_ . count) (cons `(,signer . ,(+ count 1))
(alist-delete signer stats))))))
'()
commits)))
(define commit-short-id
(compose (cut string-take <> 7) oid->string commit-id))
;;;
;;; Entry point.
;;;
(define (git-authenticate args)
(define repository
(repository-open "."))
(let loop ((args args))
(match args
((_ start end)
(define start-commit
(commit-lookup repository (string->oid start)))
(define end-commit
(commit-lookup repository (string->oid end)))
(define commits
(commit-difference end-commit start-commit))
(define reporter
(progress-reporter/bar (length commits)))
(format #t (G_ "Authenticating ~a to ~a (~a commits)...~%")
(commit-short-id start-commit)
(commit-short-id end-commit)
(length commits))
(let ((stats (call-with-progress-reporter reporter
(lambda (report)
(authenticate-commits repository commits
#:report-progress report)))))
(format #t (G_ "Signing statistics:~%"))
(for-each (match-lambda
((signer . count)
(format #t " ~a ~10d~%" signer count)))
(sort stats
(match-lambda*
(((_ . count1) (_ . count2))
(> count1 count2)))))))
((command start)
(let* ((head (repository-head repository))
(end (reference-target head)))
(loop (list command start (oid->string end)))))
(_
(format (current-error-port)
(G_ "Usage: git-authenticate START [END]
Authenticate commits START to END or the current head.\n"))))))
;;; Local Variables:
;;; eval: (put 'with-temporary-files 'scheme-indent-function 2)
;;; End:
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 21 Dec 2019 01:34:01 GMT) (full text, mbox, link).
Message #150 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi Ludo, To be honest, I do not clearly understand what the issue is concretely about. So I am probably out-of-scope and/or irrelevant. One milestone could be to have Git tags and "guix pull" would 'jump' between these tags. For an end-user like me, tags ease: a. the commit range specification (#1) b. memorize what I have already verified (#6) Moreover, it would feed a variant of OPAM path or Qubes path as you summarized here [1] or mitigate attacks if I understand the answers there [2] or [3]. [1] https://issues.guix.info/issue/22883#12 [2] https://issues.guix.info/issue/22883#15 [3] https://issues.guix.info/issue/22883#26 Thank you for all this work. All the best, simon
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 27 Dec 2019 12:59:01 GMT) (full text, mbox, link).
Message #153 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hello Guix!
Ludovic Courtès <ludo@gnu.org> skribis:
> To begin with, I propose the attached script: when given a commit range,
> it authenticates each commit, meaning that it ensures commits have a
> valid signature and that that signature was made by one of the
> authorized keys. Sample session:
>
> $ time ./pre-inst-env guile -e git-authenticate build-aux/git-authenticate.scm d68de958b60426798ed62797ff7c96c327a672ac 099ce5d4901706dc2c5be888a5c8cbf8fcd0d576
> Authenticating d68de95 to 099ce5d (7938 commits)...
> Signing statistics:
> BCA689B636553801C3C62150197A5888235FACAC 1454
> 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 1025
> BBB02DDF2CEAF6A80D1DE643A2A06DF2A33A54FA 941
>
> [...]
>
> real 2m21.272s
> user 1m38.741s
> sys 0m59.546s
I’ve now committed this file:
b3011dbbd2 doc: Mention "make authenticate".
787766ed1e git-authenticate: Keep a local cache of previously-authenticated commits.
785af04a75 git: 'commit-difference' takes a list of excluded commits.
1e43ab2c03 Add 'build-aux/git-authenticate.scm'.
Commit 787766ed1e takes care of caching (one of the limitations I
mentioned in my previous message).
Commit b3011dbbd2 adds instructions for contributors on how to
authenticate a checkout (copied below). It’s a bit bumpy so I would
very much welcome feedback and suggestions on how to improve this!
Thanks in advance!
Ludo’.
--8<---------------cut here---------------start------------->8---
If you want to hack Guix itself, it is recommended to use the latest
version from the Git repository:
git clone https://git.savannah.gnu.org/git/guix.git
How do you ensure that you obtained a genuine copy of the repository?
Guix itself provides a tool to “authenticate” your checkout, but you
must first make sure this tool is genuine in order to “bootstrap” the
trust chain. To do that, run:
git verify-commit `git log --format=%H build-aux/git-authenticate.scm`
The output must look something like:
gpg: Signature made Fri 27 Dec 2019 01:27:41 PM CET
gpg: using RSA key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
...
gpg: Signature made Fri 27 Dec 2019 01:25:22 PM CET
gpg: using RSA key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
...
... meaning that changes to this file are all signed with key
‘3CE464558A84FDC69DB40CFB090B11993D9AEBB5’ (you may need to fetch this
key from a key server, if you have not done it yet).
From there on, you can authenticate all the commits included in your
checkout by running:
make authenticate
The first run takes a couple of minutes, but subsequent runs are
faster.
Note: You are advised to run ‘make authenticate’ after every ‘git
pull’ invocation. This ensures you keep receiving valid changes to
the repository
--8<---------------cut here---------------end--------------->8---
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 27 Dec 2019 19:49:02 GMT) (full text, mbox, link).
Message #156 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Ludovic Courtès <ludo@gnu.org> writes:
> Hello,
>
> Just a note for later…
>
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> With the quick-hack libgit2 bindings attached, I can run this program,
>> which authenticates HEAD:
>
> [...]
>
>> So I think we can go from here. Our repo would contain a Scheme list of
>> authorized OpenPGP fingerprints, and we’d check whether the fingerprint
>> that shows up in ‘valid-signature’ above is among them
>
> Storing the list of authorized keys in a file in the repo is
> inconvenient: simply to retrieve it, you’d need to make a checkout. So
> for each commit we verify, we have to check out the whole repo, which is
> inefficient.
>
> While reading
> <http://karl.kornel.us/2017/10/welp-there-go-my-git-signatures/>, I
> realized we could store in empty Git commit messages, which would
> address the above problem (we could use a custom object type too, but
> that would be less convenient.)
>
> So the special commit could look like:
>
> Authorization
>
> (commit-authorizations
> (authorization-commit (KEY1 KEY2 …))
> (files ("hydra.gnu.org.pub") (KEY1 KEY2 …))
> (files _ (KEY1 KEY2 …))) ;all other files
>
> That way, to authenticate a commit, we first fetch the latest
> authorization commit, read the authorization rules from there, and make
> sure that the changes it makes match the rules.
>
> Thoughts?
Does this *have* to be baked into git? Or are we like the carpenter
apprentice who just learned how to use a hammer and considers everything
to be a kind of nail…?
I see the appeal of having everything in git as that’s where the commits
are that should be authenticated, but using special commit messages
seems to me like shoehorning update authorization into a code revision
tool.
You mentioned that checking signatures on commits is also kinda slow
because it’s sequential and not cached. I don’t know what I really
want, but is there perhaps a way to aggregate signatures on past commits
so that the client’s work is reduced…?
(I’m very glad you’re thinking about this problem and that you’ve come up
with practical steps forward! I don’t know if my thoughts on this topic
are useful.)
--
Ricardo
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 27 Dec 2019 20:48:02 GMT) (full text, mbox, link).
Message #159 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi Ludo,
> I’ve now committed this file:
>
> b3011dbbd2 doc: Mention "make authenticate".
> 787766ed1e git-authenticate: Keep a local cache of previously-authenticated commits.
> 785af04a75 git: 'commit-difference' takes a list of excluded commits.
> 1e43ab2c03 Add 'build-aux/git-authenticate.scm'.
>
> Commit 787766ed1e takes care of caching (one of the limitations I
> mentioned in my previous message).
>
> Commit b3011dbbd2 adds instructions for contributors on how to
> authenticate a checkout (copied below). It’s a bit bumpy so I would
> very much welcome feedback and suggestions on how to improve this!
This is great!
Thank you for the instructions. I thought I had all keys, but
apparently at least one of them is missing. “make authenticate” fails
for me with this error:
Throw to key `srfi-34' with args `(#<condition &message [message: "could not authenticate commit b291c9570d5a27b11472df3df61cef9ed012241b: key B943509D633E80DD27FC4EED634A8DFFD3F631DF is missing"] 7f70fb08c240>)'.
I previously downloaded the gpg keyring from Savannah:
https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix
Looks like Hartmut used to use a different key, which I don’t have.
--
Ricardo
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 28 Dec 2019 14:49:01 GMT) (full text, mbox, link).
Message #162 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hello!
Ricardo Wurmus <rekado@elephly.net> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
[...]
>> While reading
>> <http://karl.kornel.us/2017/10/welp-there-go-my-git-signatures/>, I
>> realized we could store in empty Git commit messages, which would
>> address the above problem (we could use a custom object type too, but
>> that would be less convenient.)
>>
>> So the special commit could look like:
>>
>> Authorization
>>
>> (commit-authorizations
>> (authorization-commit (KEY1 KEY2 …))
>> (files ("hydra.gnu.org.pub") (KEY1 KEY2 …))
>> (files _ (KEY1 KEY2 …))) ;all other files
>>
>> That way, to authenticate a commit, we first fetch the latest
>> authorization commit, read the authorization rules from there, and make
>> sure that the changes it makes match the rules.
>>
>> Thoughts?
>
> Does this *have* to be baked into git? Or are we like the carpenter
> apprentice who just learned how to use a hammer and considers everything
> to be a kind of nail…?
>
> I see the appeal of having everything in git as that’s where the commits
> are that should be authenticated, but using special commit messages
> seems to me like shoehorning update authorization into a code revision
> tool.
Well, I’ve changed my mind on this topic since that message. :-)
Now, the way I see it, we’d have a plain file listing authorized keys
(the file is under version control, but it’s a regular file). That
still needs to be prototyped to check whether it’s acceptable
performance-wise, but I’m more confident now.
> You mentioned that checking signatures on commits is also kinda slow
> because it’s sequential and not cached. I don’t know what I really
> want, but is there perhaps a way to aggregate signatures on past commits
> so that the client’s work is reduced…?
The caching implemented in 787766ed1e7f0806a98e696830542da528f957bb
makes things acceptable: the first “make authenticate” run takes a bit
more than two minutes to check all the commits starting from ‘v1.0.1’,
but subsequent runs take a few seconds.
I have plans to make things faster (independently of the cache) by doing
OpenPGP signature verification entirely in Scheme instead of spawning
‘gpgv’ every time. Again, we’ll have to get a prototype before we can
tell whether it actually is faster.
I hope I can spend some more time on this during the holidays, but
anyhow, feedback is much appreciated!
Thanks,
Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 28 Dec 2019 16:07:02 GMT) (full text, mbox, link).
Message #165 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Ludovic Courtès <ludo@gnu.org> writes: > The caching implemented in 787766ed1e7f0806a98e696830542da528f957bb > makes things acceptable: the first “make authenticate” run takes a bit > more than two minutes to check all the commits starting from ‘v1.0.1’, > but subsequent runs take a few seconds. This sounds good. I wonder how we would integrate this into “guix pull”. For authentication to work at all the user would have to have *all* past keys. (I’m missing at least one of the keys, because only current keys are contained in the keyring on Savannah.) > I have plans to make things faster (independently of the cache) by doing > OpenPGP signature verification entirely in Scheme instead of spawning > ‘gpgv’ every time. Again, we’ll have to get a prototype before we can > tell whether it actually is faster. More things implemented in Scheme – I love it! :) -- Ricardo
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 28 Dec 2019 17:46:02 GMT) (full text, mbox, link).
Message #168 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi, Ricardo Wurmus <rekado@elephly.net> skribis: > Ludovic Courtès <ludo@gnu.org> writes: > >> The caching implemented in 787766ed1e7f0806a98e696830542da528f957bb >> makes things acceptable: the first “make authenticate” run takes a bit >> more than two minutes to check all the commits starting from ‘v1.0.1’, >> but subsequent runs take a few seconds. > > This sounds good. > > I wonder how we would integrate this into “guix pull”. For > authentication to work at all the user would have to have *all* past > keys. (I’m missing at least one of the keys, because only current keys > are contained in the keyring on Savannah.) Right. Clearly we shouldn’t rely on key servers because it’s brittle, keys might be missing, it requires the whole GnuPG shebang to fetch a single key, etc. Instead, what I have in mind is to have a branch in the same repo containing a complete keyring of the past and current keys (say, one file per key). The machinery would thus start by loading the keyring and then use it when verifying signatures. We can generalize that to all channels: ‘.guix-channel’ could specify (1) a keyring branch, and (2) the name of a file listing authorized keys. How does that sound? Thanks, Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sun, 29 Dec 2019 02:46:01 GMT) (full text, mbox, link).
Message #171 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On 2019-12-27, Ricardo Wurmus wrote: >> b3011dbbd2 doc: Mention "make authenticate". >> 787766ed1e git-authenticate: Keep a local cache of previously-authenticated commits. >> 785af04a75 git: 'commit-difference' takes a list of excluded commits. >> 1e43ab2c03 Add 'build-aux/git-authenticate.scm'. >> >> Commit 787766ed1e takes care of caching (one of the limitations I >> mentioned in my previous message). >> >> Commit b3011dbbd2 adds instructions for contributors on how to >> authenticate a checkout (copied below). It’s a bit bumpy so I would >> very much welcome feedback and suggestions on how to improve this! > > This is great! Yes! Yes! > Thank you for the instructions. I thought I had all keys, but > apparently at least one of them is missing. “make authenticate” fails > for me with this error: > > Throw to key `srfi-34' with args `(#<condition &message [message: "could not authenticate commit b291c9570d5a27b11472df3df61cef9ed012241b: key B943509D633E80DD27FC4EED634A8DFFD3F631DF is missing"] 7f70fb08c240>)'. > > I previously downloaded the gpg keyring from Savannah: > > https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix > > Looks like Hartmut used to use a different key, which I don’t have. I got this too, and manually worked around it by downloading guix-keyring.gpg from: https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix&download=1 And running: gpg --no-default-keyring --keyring ~/.config/guix/keyrings/channels/guix.kbx --import ~/guix-keyring.gpg It seems to be working now... how is the keyring *supposed* to be populated? Before I manually imported guix-keyring.gpg into guix.kbx, there were a very small number of keys present. It's a little awkward that it uses the fingerprint of the signing key rather than the primary key, as by default things like "gpg --list-keys" do not display the fingerprint of signing keys, only the primary key, so it is an adventure in gpg commandline options to correlate them. "gpg log --show-signature" also reports the the primary key fingerprint, if the key is available in the keyring, and only the subkey fingerprint for unknown keys if I remember correctly. It would be nice if the statistics would display the primary uid instead, as it is something a little more human readable, and the primary key fingerprint, as it is a little easier to find. :) I'm hoping the eventual goal is to integrate this into guix pull? Very nice to see progress on this issue! live well, vagrant
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sun, 29 Dec 2019 07:36:02 GMT) (full text, mbox, link).
Message #174 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sat, Dec 28, 2019 at 06:45:34PM -0800, Vagrant Cascadian wrote: > On 2019-12-27, Ricardo Wurmus wrote: > >> b3011dbbd2 doc: Mention "make authenticate". > >> 787766ed1e git-authenticate: Keep a local cache of previously-authenticated commits. > >> 785af04a75 git: 'commit-difference' takes a list of excluded commits. > >> 1e43ab2c03 Add 'build-aux/git-authenticate.scm'. > >> > >> Commit 787766ed1e takes care of caching (one of the limitations I > >> mentioned in my previous message). > >> > >> Commit b3011dbbd2 adds instructions for contributors on how to > >> authenticate a checkout (copied below). It’s a bit bumpy so I would > >> very much welcome feedback and suggestions on how to improve this! > > > > This is great! > > Yes! Yes! > > > > Thank you for the instructions. I thought I had all keys, but > > apparently at least one of them is missing. “make authenticate” fails > > for me with this error: > > > > Throw to key `srfi-34' with args `(#<condition &message [message: "could not authenticate commit b291c9570d5a27b11472df3df61cef9ed012241b: key B943509D633E80DD27FC4EED634A8DFFD3F631DF is missing"] 7f70fb08c240>)'. > > > > I previously downloaded the gpg keyring from Savannah: > > > > https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix > > > > Looks like Hartmut used to use a different key, which I don’t have. > > I got this too, and manually worked around it by downloading > guix-keyring.gpg from: > > https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix&download=1 > > And running: > > gpg --no-default-keyring --keyring ~/.config/guix/keyrings/channels/guix.kbx --import ~/guix-keyring.gpg > Thanks for the hint. I started with importing the keyring into my normal keyring but I see now we have another keyring for this specifically. (another being the user default, ~/.config/guix/upstream/trustedkeys.kbx and now this one) > It seems to be working now... how is the keyring *supposed* to be > populated? Before I manually imported guix-keyring.gpg into guix.kbx, > there were a very small number of keys present. > > > It's a little awkward that it uses the fingerprint of the signing key > rather than the primary key, as by default things like "gpg --list-keys" > do not display the fingerprint of signing keys, only the primary key, so > it is an adventure in gpg commandline options to correlate them. > > "gpg log --show-signature" also reports the the primary key fingerprint, > if the key is available in the keyring, and only the subkey fingerprint > for unknown keys if I remember correctly. > > It would be nice if the statistics would display the primary uid > instead, as it is something a little more human readable, and the > primary key fingerprint, as it is a little easier to find. :) > > > I'm hoping the eventual goal is to integrate this into guix pull? > > > Very nice to see progress on this issue! > > > live well, > vagrant -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 30 Dec 2019 21:30:02 GMT) (full text, mbox, link).
Message #177 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hello! Vagrant Cascadian <vagrant@debian.org> skribis: > On 2019-12-27, Ricardo Wurmus wrote: [...] >> Thank you for the instructions. I thought I had all keys, but >> apparently at least one of them is missing. “make authenticate” fails >> for me with this error: >> >> Throw to key `srfi-34' with args `(#<condition &message [message: "could not authenticate commit b291c9570d5a27b11472df3df61cef9ed012241b: key B943509D633E80DD27FC4EED634A8DFFD3F631DF is missing"] 7f70fb08c240>)'. >> >> I previously downloaded the gpg keyring from Savannah: >> >> https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix >> >> Looks like Hartmut used to use a different key, which I don’t have. > > I got this too, and manually worked around it by downloading > guix-keyring.gpg from: > > https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix&download=1 > > And running: > > gpg --no-default-keyring --keyring ~/.config/guix/keyrings/channels/guix.kbx --import ~/guix-keyring.gpg > > It seems to be working now... how is the keyring *supposed* to be > populated? Before I manually imported guix-keyring.gpg into guix.kbx, > there were a very small number of keys present. By default, the script currently automatically downloads keys from keyserver into ~/.config/…/guix.kbx: see ‘gnupg-verify*’ in (guix gnupg). This is unreliable and rather undesirable, so the real solution will be to have the keyring in the repo. > It's a little awkward that it uses the fingerprint of the signing key > rather than the primary key, as by default things like "gpg --list-keys" > do not display the fingerprint of signing keys, only the primary key, so > it is an adventure in gpg commandline options to correlate them. > > "gpg log --show-signature" also reports the the primary key fingerprint, > if the key is available in the keyring, and only the subkey fingerprint > for unknown keys if I remember correctly. Yeah, well. Apparently ‘gpgv --status-fd’ reports the fingerprint of the subkey, not that of the primary key, which is why we’re storing the fingerprint of the subkey. I think it actually makes sense, but I wonder why ‘gpg’ makes it so hard to see the fingerprint of subkeys. > It would be nice if the statistics would display the primary uid > instead, as it is something a little more human readable, and the > primary key fingerprint, as it is a little easier to find. :) Ah, true! > I'm hoping the eventual goal is to integrate this into guix pull? Of course! Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 31 Dec 2019 19:17:02 GMT) (full text, mbox, link).
Message #180 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi Guix! Ludovic Courtès wrote: > --8<---------------cut here---------------start------------->8--- > If you want to hack Guix itself, it is recommended to use the latest > version from the Git repository: > > git clone https://git.savannah.gnu.org/git/guix.git > > How do you ensure that you obtained a genuine copy of the repository? > Guix itself provides a tool to “authenticate” your checkout, but you > must first make sure this tool is genuine in order to “bootstrap” the > trust chain. To do that, run: > > git verify-commit `git log --format=%H build-aux/git-authenticate.scm` > > The output must look something like: > > gpg: Signature made Fri 27 Dec 2019 01:27:41 PM CET > gpg: using RSA key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 > ... > gpg: Signature made Fri 27 Dec 2019 01:25:22 PM CET > gpg: using RSA key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 > ... > > ... meaning that changes to this file are all signed with key > ‘3CE464558A84FDC69DB40CFB090B11993D9AEBB5’ (you may need to fetch this > key from a key server, if you have not done it yet). > > From there on, you can authenticate all the commits included in your > checkout by running: > > make authenticate > > The first run takes a couple of minutes, but subsequent runs are > faster. > > Note: You are advised to run ‘make authenticate’ after every ‘git > pull’ invocation. This ensures you keep receiving valid changes to > the repository > --8<---------------cut here---------------end--------------->8--- Sadly, these instructions don't work from a fresh clone. There is only Makefile.am and no Makefile itself, so you get $ make authenticate make: *** No rule to make target 'authenticate'. Stop. Moreover, I don't think running 'make authenticate' after 'git pull' would really work -- after you pulled, git-authenticate could've been modified, so the verify-commit you did earlier doesn't apply anymore. There's also the issue of trusting pre-inst-env, which is used to run the verification. Should that be passed to 'git log --format=%H' next to git-authenticate.scm? This also applies to any scripts you use to drive this process, like the Makefile. Regards, Kuba
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Wed, 08 Jan 2020 13:31:01 GMT) (full text, mbox, link).
Message #183 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hello, Jakub Kądziołka <kuba@kadziolka.net> skribis: > Ludovic Courtès wrote: [...] >> How do you ensure that you obtained a genuine copy of the repository? >> Guix itself provides a tool to “authenticate” your checkout, but you >> must first make sure this tool is genuine in order to “bootstrap” the >> trust chain. To do that, run: >> >> git verify-commit `git log --format=%H build-aux/git-authenticate.scm` >> >> The output must look something like: >> >> gpg: Signature made Fri 27 Dec 2019 01:27:41 PM CET >> gpg: using RSA key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 >> ... >> gpg: Signature made Fri 27 Dec 2019 01:25:22 PM CET >> gpg: using RSA key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 >> ... >> >> ... meaning that changes to this file are all signed with key >> ‘3CE464558A84FDC69DB40CFB090B11993D9AEBB5’ (you may need to fetch this >> key from a key server, if you have not done it yet). >> >> From there on, you can authenticate all the commits included in your >> checkout by running: >> >> make authenticate >> >> The first run takes a couple of minutes, but subsequent runs are >> faster. >> >> Note: You are advised to run ‘make authenticate’ after every ‘git >> pull’ invocation. This ensures you keep receiving valid changes to >> the repository >> --8<---------------cut here---------------end--------------->8--- > > Sadly, these instructions don't work from a fresh clone. There is only > Makefile.am and no Makefile itself, so you get > > $ make authenticate > make: *** No rule to make target 'authenticate'. Stop. Uh, good point. > Moreover, I don't think running 'make authenticate' after 'git pull' > would really work -- after you pulled, git-authenticate could've been > modified, so the verify-commit you did earlier doesn't apply anymore. It works as long as I’m the only one modifying it (the instructions above explicitly mention my OpenPGP key). This is obviously suboptimal though. In a comment in ‘contributing.texi’, I wrote: @c XXX: Adjust instructions when there's a known tag to start from. That would simplify things. > There's also the issue of trusting pre-inst-env, which is used to run > the verification. Should that be passed to 'git log --format=%H' next to > git-authenticate.scm? This also applies to any scripts you use to drive > this process, like the Makefile. Yes, this ./pre-inst-env thing and more generally the fact that we’re potentially running just-pulled code to authenticate the code is a problem. We can solve it by removing ./pre-inst-env from the command in ‘make authenticate’. It will require people to have a recent-enough Guix already installed (in particular with commit f94f9d67e65975724ee5b5cbc936c0895a258685), but I think that’s unavoidable: the assumption will be that we trust the already-installed host tools and use them to authenticate the new code. Thoughts? Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Thu, 30 Apr 2020 15:33:01 GMT) (full text, mbox, link).
Message #186 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi there!
Ludovic Courtès <ludo@gnu.org> skribis:
>> You mentioned that checking signatures on commits is also kinda slow
>> because it’s sequential and not cached. I don’t know what I really
>> want, but is there perhaps a way to aggregate signatures on past commits
>> so that the client’s work is reduced…?
>
> The caching implemented in 787766ed1e7f0806a98e696830542da528f957bb
> makes things acceptable: the first “make authenticate” run takes a bit
> more than two minutes to check all the commits starting from ‘v1.0.1’,
> but subsequent runs take a few seconds.
>
> I have plans to make things faster (independently of the cache) by doing
> OpenPGP signature verification entirely in Scheme instead of spawning
> ‘gpgv’ every time. Again, we’ll have to get a prototype before we can
> tell whether it actually is faster.
I’ve been able to resume work on that in the ‘wip-openpgp’ branch:
5a86b96f54 git-authenticate: Use (guix openpgp).
4e66563449 openpgp: Add 'string->openpgp-packet'.
dc0b5d5e01 openpgp: 'lookup-key-by-{id,fingerprint}' return the key first.
740d804621 openpgp: 'verify-openpgp-signature' looks up by fingerprint when possible.
0157c5ef7f openpgp: Add 'lookup-key-by-fingerprint'.
31fc7cf080 openpgp: Store the issuer key id and fingerprint in <openpgp-signature>.
c22bede3ce openpgp: Decode the issuer-fingerprint signature subpacket.
74d0d85e49 DRAFT Add (guix openpgp).
At this stage, ‘make authenticate’ uses the pure-Scheme implementation
(based on Göran Weinholt’s code, heavily modified). It can authenticate
14K+ commits in ~20s instead of 4m20s on my laptop, which is really nice.
Signature verification in (guix openpgp) does just that: signature
verification. It does not validate signature and key metadata, in
particular expiration date. I guess it should at least error out when a
signature creation time is newer than its key expiration time.
It should also reject SHA1 signatures, at least optionally (I haven’t
checked whether our Git history has any of these).
I would very much welcome feedback and advice from an OpenPGP-savvy
person (I’ve Cc’d one to maximize the chances of success :-)).
Next steps:
• Clean up the (guix openpgp) API a bit, for instance by using proper
SRFI-35 error conditions. Perhaps handle v5 packets too.
• Load the keyring from files in the repo, possibly in a dedicated
branch.
• Load the list of authorized keys from the parent of the commit being
authenticated.
• Generalize that to channels.
Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 01 May 2020 15:47:02 GMT) (full text, mbox, link).
Message #189 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo@gnu.org> writes: > At this stage, ‘make authenticate’ uses the pure-Scheme implementation > (based on Göran Weinholt’s code, heavily modified). It can authenticate > 14K+ commits in ~20s instead of 4m20s on my laptop, which is really > nice. Neat :) > Signature verification in (guix openpgp) does just that: signature > verification. It does not validate signature and key metadata, in > particular expiration date. I guess it should at least error out when a > signature creation time is newer than its key expiration time. Indeed. I skimmed both the original and the adapted code, and it notably does no attempt to canonicalize the certificates in the keyring (i.e. checking binding signatures, lifetimes, revocations, (sub)key flags...). While that is a bit dangerous, it is okay for a point solution for Guix, provided that this is properly documented and communicated. One can forgo canonicalization if one assumes that the keyring is curated, and one has a good-list of (sub)keys fingerprints that are allowed to create signatures. Reading git-authentiate.scm that does seem to be the case. (I bet that certificate canonicalization is the major reason why calling out to gpgv is so slow: it does that every time, and it involves signature verification, which is slow (yes, I'm looking at you, RSA).) > It should also reject SHA1 signatures, at least optionally (I haven’t > checked whether our Git history has any of these). I believe it should. For reference, we reject SHA1 signatures for signatures created since 2013. > Next steps: > > • Clean up the (guix openpgp) API a bit, for instance by using proper > SRFI-35 error conditions. Perhaps handle v5 packets too. Don't bother with v5 packets for now. The RFC is nowhere near completion, and even if it is one day, it will be quite some time until you see these packets in the wild. All the best, Justus
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 01 May 2020 16:52:02 GMT) (full text, mbox, link).
Message #192 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi Justus, Justus Winter <justus@sequoia-pgp.org> skribis: > Ludovic Courtès <ludo@gnu.org> writes: [...] >> Signature verification in (guix openpgp) does just that: signature >> verification. It does not validate signature and key metadata, in >> particular expiration date. I guess it should at least error out when a >> signature creation time is newer than its key expiration time. > > Indeed. I skimmed both the original and the adapted code, and it > notably does no attempt to canonicalize the certificates in the keyring > (i.e. checking binding signatures, lifetimes, revocations, (sub)key > flags...). While that is a bit dangerous, it is okay for a point > solution for Guix, provided that this is properly documented and > communicated. > > One can forgo canonicalization if one assumes that the keyring is > curated, and one has a good-list of (sub)keys fingerprints that are > allowed to create signatures. Reading git-authentiate.scm that does > seem to be the case. Yeah, the (guix openpgp) module is good enough for this narrow use case, but I agree that people shouldn’t view it as a viable signature-only OpenPGP implementation in the general case. I’ll clarify this at least in the source file. > (I bet that certificate canonicalization is the major reason why calling > out to gpgv is so slow: it does that every time, and it involves > signature verification, which is slow (yes, I'm looking at you, RSA).) I see. >> It should also reject SHA1 signatures, at least optionally (I haven’t >> checked whether our Git history has any of these). > > I believe it should. For reference, we reject SHA1 signatures for > signatures created since 2013. Sounds good, I’ll do that. >> Next steps: >> >> • Clean up the (guix openpgp) API a bit, for instance by using proper >> SRFI-35 error conditions. Perhaps handle v5 packets too. > > Don't bother with v5 packets for now. The RFC is nowhere near > completion, and even if it is one day, it will be quite some time until > you see these packets in the wild. Alright, even better. Thanks for taking the time to look into it! Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 01 May 2020 17:05:02 GMT) (full text, mbox, link).
Message #195 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hey!
Ludovic Courtès <ludo@gnu.org> skribis:
> • Load the keyring from files in the repo, possibly in a dedicated
> branch.
>
> • Load the list of authorized keys from the parent of the commit being
> authenticated.
Done!
8916c2fa32 git-authenticate: Load the keyring from the repository.
6960064ddc git-authenticate: Load the list of authorized keys from the tree.
f145a2d1a9 .guix-authorizations: Augment.
62ae43db19 git-authenticate: Use (guix openpgp).
‘git-authenticate’ now loads the keyring from the “keyring” branch,
which I’ve just pushed as an “orphan” branch:
https://git.savannah.gnu.org/cgit/guix.git/?h=keyring
So no need to store the keyring out-of-band, to spawn gpg to fetch keys
from somewhere else, etc. The idea is that we’ll keep adding new keys
to this branch every time a new committer joins. We would never remove
keys from there because those keys are necessary to verify signatures.
The fact that a key is present on that branch does _not_ mean that it
designates an authorized committer today.
The list of authorized committers is meant to be stored in a
‘.guix-authorizations’ file in each branch of the channel. It is
essentially a list of fingerprints:
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-openpgp&id=f145a2d1a982cc841c7ccae3334d4783dad24a1e
To accept a new committer, an authorized committer must add its key to
this file in the branch(es) where that person is expected to commit.
The format currently accepts additional data for each fingerprint. It’s
currently ignored, but I thought it could be useful in the future, for
instance if we want to associate a file pattern with a key.
A commit is considered “authorized” if and only if its signing key is
listed in the ‘.guix-authorizations’ file of its parent commit(s).
In ‘git-authenticate’, this is implemented in a naive unoptimized way,
but it turns out to make no noticeable difference on the wall-clock time
to authenticate those 14K+ commits. The crux of the authorization
mechanism is this procedure:
(define* (commit-authorized-keys repository commit
#:optional (default-authorizations '()))
"Return the list of OpenPGP fingerprints authorized to sign COMMIT, based on
authorizations listed in its parent commits. If one of the parent commits
does not specify anything, fall back to DEFAULT-AUTHORIZATIONS."
…)
Feedback welcome!
Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Fri, 01 May 2020 17:21:02 GMT) (full text, mbox, link).
Message #198 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Ludovic Courtès <ludo@gnu.org> skribis:
> • Generalize that to channels.
As I see it, the generalization would be made by adding the
authentication parameters to the ‘.guix-channel’ file, along these
lines:
(channel
(version 0)
(keyring-reference "my-keyring-branch")
(historical-authorizations ".guix-authorizations.old"))
where:
• ‘keyring-reference’ specifies the branch where to look for *.key
files that constitute the keyring. It can be ‘master’ and have the
key mixed up with other files if that’s OK for the channel. By
default, it could be the current branch.
• ‘historical-authorizations’ specifies a file to load in this branch
and that contains a ‘.guix-authorizations’-formatted list of
fingerprints for commits that lack a ‘.guix-authorizations’ file.
By default, we could ignore historical commits—more specifically,
commits whose parent(s) lack(s) ‘.guix-authorizations’. It does
mean that if an authorized commit removes ‘.guix-authorizations’,
then we’re back to unauthenticated commits.
‘guix pull’ would error out before attempting to build anything if
authentication fails. It could display a warning when pulling a commit
whose parent(s) lack(s) ‘.guix-authorizations’.
Thoughts?
In terms of code, everything is already there, so it’d be mostly about
moving code around and double-checking the new data formats since
they’ll be hard to change.
In terms of processes, it’ll be tricky: if we committers make a mistake
(sign with the wrong key, forget to add a new committer’s key, etc.),
nobody is able to pull. In such a case, we’ll probably have to do a
hard-reset of the affected branch.
It would be best if we had a server-side hook to perform all these
checks, so that we don’t encounter such problems. That would mean
running some of this code on Savannah, I don’t know if it’ll be
possible. If it’s not, we can set up our own Git repo elsewhere and
make Savannah a mirror.
More thoughts? :-)
Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 02 May 2020 22:03:01 GMT) (full text, mbox, link).
Message #201 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Ludovic Courtès <ludo@gnu.org> skribis: > Next steps: > > • Clean up the (guix openpgp) API a bit, for instance by using proper > SRFI-35 error conditions. Done the API cleanup. I’ll go ahead and push the current ‘wip-openpgp’ branch (squashing commits marked as such) tomorrow if there are no objections. The formats and mechanisms are not set in stone until this is generalized to channels, but we’re getting there. Now’s a good time to raise any concerns you may have, comrades! Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 04 May 2020 08:04:02 GMT) (full text, mbox, link).
Message #204 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi!
Ludovic Courtès <ludo@gnu.org> skribis:
> Done the API cleanup. I’ll go ahead and push the current ‘wip-openpgp’
> branch (squashing commits marked as such) tomorrow if there are no
> objections.
Pushed on master!
4a84deda74 doc: Recommend against SHA1 OpenPGP signatures.
84133320b8 doc: Document committer authorization.
05d973eef2 openpgp: Raise error conditions instead of calling 'error'.
041dc3a9c0 git-authenticate: Load the keyring from the repository.
92db1036b7 git-authenticate: Load the list of authorized keys from the tree.
bee5b7a0f8 .guix-authorizations: Augment.
051a45e642 git-authenticate: Use (guix openpgp).
b835e158d5 openpgp: Add 'string->openpgp-packet'.
bd8126558d openpgp: 'lookup-key-by-{id,fingerprint}' return the key first.
b45fa0a123 openpgp: 'verify-openpgp-signature' looks up by fingerprint when possible.
efe1f0122c openpgp: Add 'lookup-key-by-fingerprint'.
7b2b3a13cc openpgp: Store the issuer key id and fingerprint in <openpgp-signature>.
4459c7859c openpgp: Decode the issuer-fingerprint signature subpacket.
43408e304f Add (guix openpgp).
c91e27c608 Add '.guix-authorizations'.
> The formats and mechanisms are not set in stone until this is
> generalized to channels, but we’re getting there. Now’s a good time to
> raise any concerns you may have, comrades!
Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 19 May 2020 20:24:02 GMT) (full text, mbox, link).
Message #207 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hello! Ludovic Courtès <ludo@gnu.org> skribis: > The list of authorized committers is meant to be stored in a > ‘.guix-authorizations’ file in each branch of the channel. It is > essentially a list of fingerprints: > > https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-openpgp&id=f145a2d1a982cc841c7ccae3334d4783dad24a1e > > To accept a new committer, an authorized committer must add its key to > this file in the branch(es) where that person is expected to commit. > The format currently accepts additional data for each fingerprint. It’s > currently ignored, but I thought it could be useful in the future, for > instance if we want to associate a file pattern with a key. > > A commit is considered “authorized” if and only if its signing key is > listed in the ‘.guix-authorizations’ file of its parent commit(s). The good news with this model is that an adversary cannot trick users into fetching an unrelated branch where the authorizations would be different: they can always detect that it’s a disconnected branch or that it’s not a fast-forward pull. The bad news is that this also prevents “unauthorized forks” in general. Unless Guix folks explicitly push a commit authorizing the key of the person who forks, commits by that person will appear as unauthorized. So we need an extra mechanism to say: “this fork starts here”. However, modifications to that piece of information must be detectable so that one cannot serve a malicious fork that pretends to forego history. Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 01 Jun 2020 14:08:02 GMT) (full text, mbox, link).
Message #210 received at 22883@debbugs.gnu.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi!
Ludovic Courtès <ludo@gnu.org> skribis:
> The good news with this model is that an adversary cannot trick users
> into fetching an unrelated branch where the authorizations would be
> different: they can always detect that it’s a disconnected branch or
> that it’s not a fast-forward pull.
>
> The bad news is that this also prevents “unauthorized forks” in general.
> Unless Guix folks explicitly push a commit authorizing the key of the
> person who forks, commits by that person will appear as unauthorized.
>
> So we need an extra mechanism to say: “this fork starts here”. However,
> modifications to that piece of information must be detectable so that
> one cannot serve a malicious fork that pretends to forego history.
We have two issues to address: (1) bootstraping trust in a channel the
first time ‘guix pull’ obtains it, and (2) supporting “unauthorized”
forks as described above. The two are very similar.
I think we need a way to “introduce” a channel to its users that goes
beyond a mere URL.
It should be possible to obtain a “channel introduction” out-of-band
(i.e., not in the channel’s repo). For example, the introduction to the
official ‘guix’ channel would be in ‘%default-channels’, in (guix
channels), which users obtained in the binary tarball or ISO. For other
channels where there’s no practical out-of-band transmission of the
introduction, it would very much be trust-on-first-use (TOFU).
I think the introduction needs to include:
1. The commit used as a starting point for ‘.guix-authorizations’
checks.
2. The OpenPGP fingerprint of the signer of this first commit.
3. A signature over this commit/fingerprint pair made by the signer of
the commit.
Rationale
~~~~~~~~~
1. The ‘guix’ channel and others will have their authorization start
long after their initial commit. Thus, authors need to state where
to start the authentication process. (Currently the starting point
is hard-coded in ‘Makefile.am’ and passed as an argument to
‘build-aux/git-authenticate.scm’.)
If that information were stored in ‘.guix-channel’, it would be
trivial for an attacker to fork the project (or push a new commit)
and pretend the authentication process must not take previous
commits into account.
2. The fingerprint of the signer of the initial commit makes it easy
for ‘guix pull’ to verify that initial commit on its first clone.
3. The signature over the commit/fingerprint pair makes sure that it
was emitted by an authorized party. Without it, anyone could emit
a channel introduction that skips over a range of commits.
4. When publishing a fork of a channel, one emits a new channel
introduction. Users switching to the fork have to explicitly allow
that new channel via its introduction; flipping the URL won’t be
enough because ‘guix pull’ would report unauthorized commits.
5. The channel URL is not included in the introduction. However, the
official URL is an important piece of information: it tells users
this is where they’ll get the latest updates. It should be
possible to create mirrors, but by default users should go to the
official URL. They should be aware that mirrors can be outdated.
I think the official URL can be stored in ‘.guix-channel’ in the
repo (which is subject to the authentication machinery). That way,
‘guix pull’ can let the user know if they’re talking to a mirror
rather than to the official channel.
Prototype
~~~~~~~~~
The attached code creates channel introductions. One implementation
uses a “compact” binary encoding, which, one encoded in Radix-64, looks
like this:
-----BEGIN GUIX CHANNEL INTRODUCTION-----
R1hDSQAAAAAAFJdEzHtGNvr7dyyUrbjwWWG1s58WPORkVYqE/cadtAz7CQsRmT2a67UCvaMBAbYC
Sf2QDQMACgEJCxGZPZrrtQHLb2IAXtUHUCgoY29tbWl0ICI5NzQ0Y2M3YjQ2MzZmYWZiNzcyYzk0
YWRiOGYwNTk2MWI1YjM5ZjE2IikgKHNpZ25lciAiM2NlNDY0NTU4YTg0ZmRjNjlkYjQwY2ZiMDkw
YjExOTkzZDlhZWJiNSIpKYkCMwQAAQoAHRYhBDzkZFWKhP3GnbQM+wkLEZk9muu1BQJe1QdQAAoJ
EAkLEZk9muu1SlUQAIQVO6JeNmDywM5bAVIktX0VbPmPl0CNCt2oTN8jPZ30lwa3osckOEa2LqQv
0xP59n9tPUue8rXoACcdZ4RS7fZeWjn9qBGCr7h/cQIS0p7II08jHccovvEfgQGxqQCe5hZ++Ehv
OyKV84bG3VOxLFe7B2wIqoIAtmFYCeNmqBfOixSWgzCwC/G5fh7frXR+O9BzvhfBVeFSgzgayNnu
GxgO+Jx7ZhnxR8rRIxrOxCEUjbi8ilIhw++z4ea7g4yTFCkmpPY54HIhzgERanm0/iJUBj9nv9kQ
TXnJ2dcFeZL7b+fWdh8kiKaTgYKV3BGQOKpdqSBQcV9Ys+FFJ+I5ZRCzmTxafPLmR8eGM3aT4Fld
drCjSHga4hbppQJPpNyKsrhwJ4d5tLuLHYUNlXEhcYi11Uo2i30T+TbOynD/uWFRY1+s0ffI1LmX
FhSaqk44jfQoXYeeS8FO471ze3087fsp2WVwNZ5kdPOFNa1Iv+uj/CDILsb4kooRrawQod2W7eb6
jMCayWCUApah22BisQepkFVtKeEAG6aSkIa6Haq4ZrEtzz9gu4n6Pmgv60+n3t77rb7GbPafdSKu
LiJ8PeYSBR3II2YdjIn9PTQ75Xg90IeFxt5PF70q/yb/WoRTIokHFho1QEmbmAm1HBO8SVlmHG+X
8WFn7ex7cx3iYH6H
=xZUu
-----END GUIX CHANNEL INTRODUCTION-----
(guix channels) could provide a ‘channel-introduction->channel’
procedure. In ~/.config/guix/channels.scm, one would write:
(list (channel-introduction->channel "https://…"
"\
-----BEGIN GUIX CHANNEL INTRODUCTION-----
…"))
The introduction needs to be decoded and checked only the first time
‘guix pull’ encounters a channel.
This verbose interface creates an incentive to create a ‘guix channel’
command that could make it easier to add a new channel.
Thoughts?
Ludo’.
[channel-intro.scm (text/plain, inline)]
(use-modules (guix)
(gcrypt pk-crypto)
(gcrypt base16)
(gcrypt base64)
(srfi srfi-1)
(srfi srfi-71)
(ice-9 popen)
(ice-9 match)
(guix utils)
(guix build utils)
((guix openpgp) #:select (openpgp-format-fingerprint))
(rnrs bytevectors)
(rnrs io ports))
(define url
"https://git.savannah.gnu.org/git/guix.git")
(define commit
"9744cc7b4636fafb772c94adb8f05961b5b39f16")
(define signer
(base16-string->bytevector
"3ce464558a84fdc69db40cfb090b11993d9aebb5"))
(define (sign-introduction commit signer)
(let ((pipe pids
(filtered-port (list (which "gpg") "-s" "-u"
(bytevector->base16-string signer))
(open-input-string
(object->string
`((commit ,commit)
(signer
,(bytevector->base16-string signer))))))))
(let ((bv (get-bytevector-all pipe)))
(and (every (compose zero? cdr waitpid) pids)
bv))))
(define (channel-introduction commit signer)
"Return an sexp representing a channel introduction."
`(channel-introduction
(version 0)
(commit ,commit)
(signer ,(openpgp-format-fingerprint signer))
(signature ,(base64-encode (sign-introduction commit signer)))))
(define (radix-64-encode bv)
(define (int24->bv int)
(let ((bv (make-bytevector 3)))
(bytevector-u8-set! bv 0 (ash (logand int #xff0000) -16))
(bytevector-u8-set! bv 1 (ash (logand int #x00ff00) -8))
(bytevector-u8-set! bv 2 (logand int #x0000ff))
bv))
(let ((str (base64-encode bv)))
(string-append "-----BEGIN GUIX CHANNEL INTRODUCTION-----\n\n"
(insert-newlines str)
"="
(base64-encode
(int24->bv ((@@ (guix openpgp) crc24) bv)))
"\n\n"
"-----END GUIX CHANNEL INTRODUCTION-----\n")))
(define* (insert-newlines str #:optional (line-length 76))
"Insert newlines in STR every LINE-LENGTH characters."
(let loop ((result '())
(str str))
(if (string-null? str)
(string-concatenate-reverse result)
(let* ((length (min (string-length str) line-length))
(prefix (string-take str length))
(suffix (string-drop str length)))
(loop (cons (string-append prefix "\n") result)
suffix)))))
(radix-64-encode
(string->utf8 (object->string (channel-introduction commit signer))))
(define (channel-introduction/compact commit signer)
"Return a channel introduction as a bytevector, in compact binary
encoding."
(let ((port get (open-bytevector-output-port)))
(put-bytevector port
(u8-list->bytevector
(map char->integer (string->list "GXCI"))))
(put-bytevector port #vu8(0 0 0 0)) ;version
(let ((commit (base16-string->bytevector commit))
(len (make-bytevector 2)))
(bytevector-u16-set! len 0 (bytevector-length commit)
(endianness big))
(put-bytevector port len)
(put-bytevector port commit))
(put-bytevector port signer)
(let ((signature (sign-introduction commit signer))
(len (make-bytevector 2)))
(bytevector-u16-set! len 0 (bytevector-length signature)
(endianness big))
(put-bytevector port len)
(put-bytevector port signature))
(force-output port)
(get)))
(radix-64-encode
(channel-introduction/compact commit signer))
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 02 Jun 2020 13:50:01 GMT) (full text, mbox, link).
Message #213 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi Ludo, I like this idea a lot since I use a checkout which I guess constitutes a "fork" in this scenario. I opened bug#41604 (http://issues.guix.gnu.org/issue/41604) after having trouble with a rebase based workflow. Some of my problems certainly come from my lack of understanding of the authentication process and machinery. Would the channel introduction allow me to use the rebase workflow in my checkout? I am not sure I am clear on how I would setup an introduction for my local checkout. Heck, I am still trying to figure out how to add myself as a signer to my patches on top of master. Thanks as always, John
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 02 Jun 2020 23:46:02 GMT) (full text, mbox, link).
Message #216 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi Ludo,
Really cool!
Well, even if I am not enough clever to understand all that.
On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès <ludo@gnu.org> wrote:
> I think we need a way to “introduce” a channel to its users that goes
> beyond a mere URL.
Just to be sure to well understand, will the good ol'
~/.config/guix/channels.scm
--8<---------------cut here---------------start------------->8---
;; Tell 'guix pull' to use my own repo.
(list (channel
(name 'guix)
(url "https://example.org/my-guix.git")
(branch "super-hacks")))
--8<---------------cut here---------------end--------------->8---
still work as it is now? i.e., using the current "unauthorized"
mechanism. Or will a new keyword be added to this channel description
to say "this channel does not use authorized machinery but it is
fine"?
> If that information were stored in ‘.guix-channel’, it would be
> trivial for an attacker to fork the project (or push a new commit)
> and pretend the authentication process must not take previous
> commits into account.
What will happen to recursive '.guix-channel'? The '.guix-channel' of
channel A contains the reference to the channel B where the
'.guix-channel' contains the reference to the channel C, etc.
> 4. When publishing a fork of a channel, one emits a new channel
> introduction. Users switching to the fork have to explicitly allow
> that new channel via its introduction; flipping the URL won’t be
> enough because ‘guix pull’ would report unauthorized commits.
I am a bit afraid by this... and I hope that a fork of a channel will
still work without emitting a new channel introduction.
> 5. The channel URL is not included in the introduction. However, the
> official URL is an important piece of information: it tells users
> this is where they’ll get the latest updates. It should be
> possible to create mirrors, but by default users should go to the
> official URL. They should be aware that mirrors can be outdated.
I do not understand this paragraph. The aim of mirrors is to avoid
the users to go to the official URL, isn't it? And the mirrors do not
have by design the latest updates (time to propagate, etc.).
> I think the official URL can be stored in ‘.guix-channel’ in the
> repo (which is subject to the authentication machinery). That way,
> ‘guix pull’ can let the user know if they’re talking to a mirror
> rather than to the official channel.
Why does it matter? The user should authenticate the downloaded
content whatever the URL serving it, isn't it?
And can 'guix pull' already let the users know to who they are talking?
> This verbose interface creates an incentive to create a ‘guix channel’
> command that could make it easier to add a new channel.
Yahoga! :-)
Thank you.
All the best,
simon
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Wed, 03 Jun 2020 09:34:01 GMT) (full text, mbox, link).
Message #219 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi, John Soo <jsoo1@asu.edu> skribis: > I like this idea a lot since I use a checkout which I guess constitutes > a "fork" in this scenario. I opened bug#41604 > (http://issues.guix.gnu.org/issue/41604) after having trouble with a > rebase based workflow. Some of my problems certainly come from my lack > of understanding of the authentication process and machinery. Would the > channel introduction allow me to use the rebase workflow in my checkout? No. Note that the authentication code is not used at all by ‘guix pull’ currently. When all this is in place, channel introductions would be how you publish your own channel such that ‘guix pull’ can consume it. But as I wrote in the other issue, a rebase workflow is not supported by ‘guix pull’ (just like it’s not supported by ‘git pull’ actually). HTH! Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Wed, 03 Jun 2020 09:51:02 GMT) (full text, mbox, link).
Message #222 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi, zimoun <zimon.toutoune@gmail.com> skribis: > On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès <ludo@gnu.org> wrote: > >> I think we need a way to “introduce” a channel to its users that goes >> beyond a mere URL. > > Just to be sure to well understand, will the good ol' > ~/.config/guix/channels.scm > > ;; Tell 'guix pull' to use my own repo. > (list (channel > (name 'guix) > (url "https://example.org/my-guix.git") > (branch "super-hacks"))) > > still work as it is now? i.e., using the current "unauthorized" > mechanism. Or will a new keyword be added to this channel description > to say "this channel does not use authorized machinery but it is > fine"? Yeah, we have to keep it working. So I guess in that case it would just emit a warning saying this channel is not authenticated, and that’s it. >> If that information were stored in ‘.guix-channel’, it would be >> trivial for an attacker to fork the project (or push a new commit) >> and pretend the authentication process must not take previous >> commits into account. > > What will happen to recursive '.guix-channel'? The '.guix-channel' of > channel A contains the reference to the channel B where the > '.guix-channel' contains the reference to the channel C, etc. I’m not sure I understand. (The sentence above is about *not* storing info in ‘.guix-channel’.) >> 4. When publishing a fork of a channel, one emits a new channel >> introduction. Users switching to the fork have to explicitly allow >> that new channel via its introduction; flipping the URL won’t be >> enough because ‘guix pull’ would report unauthorized commits. > > I am a bit afraid by this... and I hope that a fork of a channel will > still work without emitting a new channel introduction. No, when publishing a fork of an authenticated channel, you’ll have to publish its introduction alongside its URL. I think it’s unavoidable: we want to be able to distinguish between a mirror that has been tampered with and a fork. >> 5. The channel URL is not included in the introduction. However, the >> official URL is an important piece of information: it tells users >> this is where they’ll get the latest updates. It should be >> possible to create mirrors, but by default users should go to the >> official URL. They should be aware that mirrors can be outdated. > > I do not understand this paragraph. The aim of mirrors is to avoid > the users to go to the official URL, isn't it? And the mirrors do not > have by design the latest updates (time to propagate, etc.). > > >> I think the official URL can be stored in ‘.guix-channel’ in the >> repo (which is subject to the authentication machinery). That way, >> ‘guix pull’ can let the user know if they’re talking to a mirror >> rather than to the official channel. > > Why does it matter? The user should authenticate the downloaded > content whatever the URL serving it, isn't it? > And can 'guix pull' already let the users know to who they are talking? You’re right: ideally the URL wouldn’t matter at all. However, from a security perspective, we not only want to make sure users get genuine commits, we also want to know they’re not talking to a possibly outdated mirror. Since there’s no way to answer the question “is this the latest commit?” in a general way, the best we can do, I think, is to detect whether we’re talking to the “official” Git repo. Thanks for your feedback! Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Wed, 03 Jun 2020 16:21:02 GMT) (full text, mbox, link).
Message #225 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi Ludo, Thank you for the explanations. On Wed, 3 Jun 2020 at 11:50, Ludovic Courtès <ludo@gnu.org> wrote: > zimoun <zimon.toutoune@gmail.com> skribis: > > On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès <ludo@gnu.org> wrote: > >> If that information were stored in ‘.guix-channel’, it would be > >> trivial for an attacker to fork the project (or push a new commit) > >> and pretend the authentication process must not take previous > >> commits into account. > > > > What will happen to recursive '.guix-channel'? The '.guix-channel' of > > channel A contains the reference to the channel B where the > > '.guix-channel' contains the reference to the channel C, etc. > > I’m not sure I understand. (The sentence above is about *not* storing > info in ‘.guix-channel’.) Sorry, I have misread. The question about recursive still applies. ;-) Currently, if the local channel file points to a channel A which contains the file '.guix-channel' which points to another channel B, then when one runs "guix pull" well the channel A will be pulled and then the channel B, even if this channel B is not explicit in the initial local channel. (Even, there is bug about recursive implicit pulls, see http://issues.guix.gnu.org/issue/41069; well another story.) What happens for such situation? > >> I think we need a way to “introduce” a channel to its users that goes > >> beyond a mere URL. > > > > Just to be sure to well understand, will the good ol' > > ~/.config/guix/channels.scm > > > > ;; Tell 'guix pull' to use my own repo. > > (list (channel > > (name 'guix) > > (url "https://example.org/my-guix.git") > > (branch "super-hacks"))) > > > > still work as it is now? i.e., using the current "unauthorized" > > mechanism. Or will a new keyword be added to this channel description > > to say "this channel does not use authorized machinery but it is > > fine"? > > Yeah, we have to keep it working. So I guess in that case it would just > emit a warning saying this channel is not authenticated, and that’s it. [...] > >> 4. When publishing a fork of a channel, one emits a new channel > >> introduction. Users switching to the fork have to explicitly allow > >> that new channel via its introduction; flipping the URL won’t be > >> enough because ‘guix pull’ would report unauthorized commits. > > > > I am a bit afraid by this... and I hope that a fork of a channel will > > still work without emitting a new channel introduction. > > No, when publishing a fork of an authenticated channel, you’ll have to > publish its introduction alongside its URL. I do not understand your two answers. Well, there is 4 situations when publishing: 1- an authenticated fork of an authenticated channel 2- an authenticated fork of an unauthenticated channel 3- an unauthenticated fork of an authenticated channel 4- an unauthenticated fork of an unauthenticated channel "authenticated channel" means a channel using all the authentication machinery. "authenticated fork" means add a "channel introduction" and so become a "authenticate channel" then. Today, we are in the situation 4. and we are going to the 1. if I understand correctly. And if I understand your answer above about good ol' channel, the 4. will still work and emit a warning, isn't it? What about the 2. and 3.? These situations correspond to: 1- the correct way 2- bootstrap the trust 3- and 4- quick and dirty "Scientific" workflows where the security is not a concern. > I think it’s unavoidable: we want to be able to distinguish between a > mirror that has been tampered with and a fork. I understand. But this break the symmetry and the distributed model of Guix, IMHO. > >> 5. The channel URL is not included in the introduction. However, the > >> official URL is an important piece of information: it tells users > >> this is where they’ll get the latest updates. It should be > >> possible to create mirrors, but by default users should go to the > >> official URL. They should be aware that mirrors can be outdated. > > > > I do not understand this paragraph. The aim of mirrors is to avoid > > the users to go to the official URL, isn't it? And the mirrors do not > > have by design the latest updates (time to propagate, etc.). > > > >> I think the official URL can be stored in ‘.guix-channel’ in the > >> repo (which is subject to the authentication machinery). That way, > >> ‘guix pull’ can let the user know if they’re talking to a mirror > >> rather than to the official channel. > > > > Why does it matter? The user should authenticate the downloaded > > content whatever the URL serving it, isn't it? > > And can 'guix pull' already let the users know to who they are talking? > > You’re right: ideally the URL wouldn’t matter at all. However, from a > security perspective, we not only want to make sure users get genuine > commits, we also want to know they’re not talking to a possibly outdated > mirror. Genuine commits and outdated mirrors are separated questions, IMHO. > Since there’s no way to answer the question “is this the latest commit?” > in a general way, the best we can do, I think, is to detect whether > we’re talking to the “official” Git repo. What does "official" mean here? To me, it means commits that I trust, i.e., approved by an authority. My local clone is not less "official" than the repo on Savannah. I do not understand why the question “is this the latest commit?” has to be answered. If an user wants the latest commits, then they directly pulls from upstream, i.e, from Savannah. If an user wants to pull from a mirror for whatever reasons, then they knows that the last updates are not necessary there, since it is a mirror and not upstream -- and it is the responsibility of the mirror maintainer to keep it up-to-date. However, what the user wants to know is whether the mirror has not introduced malicious commits. Thank you for all that. Cheers, simon
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Thu, 04 Jun 2020 09:56:01 GMT) (full text, mbox, link).
Message #228 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi, zimoun <zimon.toutoune@gmail.com> skribis: > On Wed, 3 Jun 2020 at 11:50, Ludovic Courtès <ludo@gnu.org> wrote: >> zimoun <zimon.toutoune@gmail.com> skribis: >> > On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès <ludo@gnu.org> wrote: > >> >> If that information were stored in ‘.guix-channel’, it would be >> >> trivial for an attacker to fork the project (or push a new commit) >> >> and pretend the authentication process must not take previous >> >> commits into account. >> > >> > What will happen to recursive '.guix-channel'? The '.guix-channel' of >> > channel A contains the reference to the channel B where the >> > '.guix-channel' contains the reference to the channel C, etc. >> >> I’m not sure I understand. (The sentence above is about *not* storing >> info in ‘.guix-channel’.) > > Sorry, I have misread. > The question about recursive still applies. ;-) > Currently, if the local channel file points to a channel A which > contains the file '.guix-channel' which points to another channel B, > then when one runs "guix pull" well the channel A will be pulled and > then the channel B, even if this channel B is not explicit in the > initial local channel. (Even, there is bug about recursive implicit > pulls, see http://issues.guix.gnu.org/issue/41069; well another > story.) > > What happens for such situation? Nothing special, I guess: each channel would be authenticated (or not, if it’s an unsigned channel). I think it’s completely orthogonal. >> >> 4. When publishing a fork of a channel, one emits a new channel >> >> introduction. Users switching to the fork have to explicitly allow >> >> that new channel via its introduction; flipping the URL won’t be >> >> enough because ‘guix pull’ would report unauthorized commits. >> > >> > I am a bit afraid by this... and I hope that a fork of a channel will >> > still work without emitting a new channel introduction. >> >> No, when publishing a fork of an authenticated channel, you’ll have to >> publish its introduction alongside its URL. > > I do not understand your two answers. Well, there is 4 situations > when publishing: > > 1- an authenticated fork of an authenticated channel > 2- an authenticated fork of an unauthenticated channel > 3- an unauthenticated fork of an authenticated channel > 4- an unauthenticated fork of an unauthenticated channel > > "authenticated channel" means a channel using all the authentication machinery. > "authenticated fork" means add a "channel introduction" and so become > a "authenticate channel" then. I’m sorry, I don’t follow the terminology. > Today, we are in the situation 4. and we are going to the 1. if I > understand correctly. > And if I understand your answer above about good ol' channel, the 4. > will still work and emit a warning, isn't it? > What about the 2. and 3.? > > These situations correspond to: > > 1- the correct way > 2- bootstrap the trust > 3- and 4- quick and dirty "Scientific" workflows where the security is > not a concern. Funny how “scientific” has become synonymous with “quick-and-dirty” these days… […] > Genuine commits and outdated mirrors are separated questions, IMHO. > > >> Since there’s no way to answer the question “is this the latest commit?” >> in a general way, the best we can do, I think, is to detect whether >> we’re talking to the “official” Git repo. > > What does "official" mean here? To me, it means commits that I trust, > i.e., approved by an authority. My local clone is not less "official" > than the repo on Savannah. > > I do not understand why the question “is this the latest commit?” has > to be answered. If an user wants the latest commits, then they > directly pulls from upstream, i.e, from Savannah. If an user wants to > pull from a mirror for whatever reasons, then they knows that the last > updates are not necessary there, since it is a mirror and not upstream > -- and it is the responsibility of the mirror maintainer to keep it > up-to-date. However, what the user wants to know is whether the > mirror has not introduced malicious commits. Guix is a software supply tool. There are two important security questions a software supply client must address: “am I getting the authentic stuff?”, and “am I getting the latest stuff?”. The first one is obvious, the second one relates to “downgrade attacks” which can introduce known security vulnerabilities. Things like The Update Framework (TUF) address both, but they do that in a context that’s technically “like Debian” (binary distro) and very different from Guix. Yet, these two issues must also be addressed in Guix, like in any other distro. What we’ve been discussing here addresses the first question. For the second question, the best answer I came up with is that of an “official URL”, allowing users to know the URL that should give them the latest stuff. “Official” means that it genuinely comes from the organization I entrusted with my computer, be it the Guix project, another organization maintaining a Guix fork, or an organization maintaining a Guix channel. I hope that makes sense. Thanks, Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 08 Jun 2020 21:55:03 GMT) (full text, mbox, link).
Message #231 received at 22883@debbugs.gnu.org (full text, mbox, reply):
* guix/git-authenticate.scm (authenticated-commit-cache-file)
(cache-authenticated-commit, previously-authenticated-commits): Add
'key' parameter and honor it.
* build-aux/git-authenticate.scm (git-authenticate): Pass
"channels/guix" as the key.
---
build-aux/git-authenticate.scm | 5 +++--
guix/git-authenticate.scm | 24 ++++++++++++------------
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/build-aux/git-authenticate.scm b/build-aux/git-authenticate.scm
index 5e1fdaaa24..a3d4b40ccf 100644
--- a/build-aux/git-authenticate.scm
+++ b/build-aux/git-authenticate.scm
@@ -252,7 +252,7 @@
(filter-map (lambda (id)
(false-if-exception
(commit-lookup repository (string->oid id))))
- (previously-authenticated-commits)))
+ (previously-authenticated-commits "channels/guix")))
(define commits
;; Commits to authenticate, excluding the closure of
@@ -274,7 +274,8 @@
#:default-authorizations
%historical-authorized-signing-keys
#:report-progress report)))))
- (cache-authenticated-commit (oid->string (commit-id end-commit)))
+ (cache-authenticated-commit "channels/guix"
+ (oid->string (commit-id end-commit)))
(unless (null? stats)
(format #t (G_ "Signing statistics:~%"))
diff --git a/guix/git-authenticate.scm b/guix/git-authenticate.scm
index c333717136..6d71228d72 100644
--- a/guix/git-authenticate.scm
+++ b/guix/git-authenticate.scm
@@ -272,33 +272,33 @@ The OpenPGP keyring is loaded from KEYRING-REFERENCE in REPOSITORY."
;;; Caching.
;;;
-(define (authenticated-commit-cache-file)
+(define (authenticated-commit-cache-file key)
"Return the name of the file that contains the cache of
-previously-authenticated commits."
- (string-append (cache-directory) "/authentication/channels/guix"))
+previously-authenticated commits for KEY."
+ (string-append (cache-directory) "/authentication/" key))
-(define (previously-authenticated-commits)
- "Return the previously-authenticated commits as a list of commit IDs (hex
-strings)."
+(define (previously-authenticated-commits key)
+ "Return the previously-authenticated commits under KEY as a list of commit
+IDs (hex strings)."
(catch 'system-error
(lambda ()
- (call-with-input-file (authenticated-commit-cache-file)
+ (call-with-input-file (authenticated-commit-cache-file key)
read))
(lambda args
(if (= ENOENT (system-error-errno args))
'()
(apply throw args)))))
-(define (cache-authenticated-commit commit-id)
- "Record in ~/.cache COMMIT-ID and its closure as authenticated (only
-COMMIT-ID is written to cache, though)."
+(define (cache-authenticated-commit key commit-id)
+ "Record in ~/.cache, under KEY, COMMIT-ID and its closure as
+authenticated (only COMMIT-ID is written to cache, though)."
(define %max-cache-length
;; Maximum number of commits in cache.
200)
(let ((lst (delete-duplicates
- (cons commit-id (previously-authenticated-commits))))
- (file (authenticated-commit-cache-file)))
+ (cons commit-id (previously-authenticated-commits key))))
+ (file (authenticated-commit-cache-file key)))
(mkdir-p (dirname file))
(with-atomic-file-output file
(lambda (port)
--
2.26.2
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 08 Jun 2020 21:55:03 GMT) (full text, mbox, link).
Message #234 received at 22883@debbugs.gnu.org (full text, mbox, reply):
* guix/git-authenticate.scm (authenticate-commits): Add #:keyring
parameter.
---
guix/git-authenticate.scm | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/guix/git-authenticate.scm b/guix/git-authenticate.scm
index 6d71228d72..4795ccf12a 100644
--- a/guix/git-authenticate.scm
+++ b/guix/git-authenticate.scm
@@ -248,13 +248,13 @@ an OpenPGP keyring."
#:key
(default-authorizations '())
(keyring-reference "keyring")
+ (keyring (load-keyring-from-reference
+ repository keyring-reference))
(report-progress (const #t)))
"Authenticate COMMITS, a list of commit objects, calling REPORT-PROGRESS for
each of them. Return an alist showing the number of occurrences of each key.
-The OpenPGP keyring is loaded from KEYRING-REFERENCE in REPOSITORY."
- (define keyring
- (load-keyring-from-reference repository keyring-reference))
-
+If KEYRING is omitted, the OpenPGP keyring is loaded from KEYRING-REFERENCE in
+REPOSITORY."
(fold (lambda (commit stats)
(report-progress)
(let ((signer (authenticate-commit repository commit keyring
--
2.26.2
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 08 Jun 2020 21:55:04 GMT) (full text, mbox, link).
Message #237 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Fixes <https://bugs.gnu.org/22883>.
* guix/channels.scm (<channel>)[introduction]: New field.
(<channel-introduction>): New record type.
(%guix-channel-introduction): New variable.
(%default-channels): Use it.
(<channel-metadata>)[keyring-reference]: New field.
(%default-keyring-reference): New variable.
(read-channel-metadata, read-channel-metadata-from-source): Initialize
the 'keyring-reference' field.
(commit-short-id, verify-introductory-commit)
(authenticate-channel): New procedures.
(latest-channel-instance): Call 'authenticate-channel' when CHANNEL has
an introduction.
* tests/channels.scm (gpg+git-available?, commit-id-string): New
procedures.
("authenticate-channel, wrong first commit signer"):
("authenticate-channel, .guix-authorizations"): New tests.
* doc/guix.texi (Invoking guix pull): Mention authentication.
---
.dir-locals.el | 1 +
doc/guix.texi | 6 +-
guix/channels.scm | 182 +++++++++++++++++++++++++++++++++++++++++++--
tests/channels.scm | 122 ++++++++++++++++++++++++++++++
4 files changed, 304 insertions(+), 7 deletions(-)
diff --git a/.dir-locals.el b/.dir-locals.el
index dc8bc0e437..7ac1eb7509 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -95,6 +95,7 @@
(eval . (put 'eventually 'scheme-indent-function 1))
(eval . (put 'call-with-progress-reporter 'scheme-indent-function 1))
+ (eval . (put 'with-repository 'scheme-indent-function 2))
(eval . (put 'with-temporary-git-repository 'scheme-indent-function 2))
(eval . (put 'with-environment-variables 'scheme-indent-function 1))
(eval . (put 'with-fresh-gnupg-setup 'scheme-indent-function 1))
diff --git a/doc/guix.texi b/doc/guix.texi
index 056bf011f6..6fcb47970b 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -3719,13 +3719,17 @@ this option is primarily useful when the daemon was running with
@cindex updating Guix
@cindex @command{guix pull}
@cindex pull
+@cindex security, @command{guix pull}
+@cindex authenticity, of code obtained with @command{guix pull}
Packages are installed or upgraded to the latest version available in
the distribution currently available on your local machine. To update
that distribution, along with the Guix tools, you must run @command{guix
pull}: the command downloads the latest Guix source code and package
descriptions, and deploys it. Source code is downloaded from a
@uref{https://git-scm.com, Git} repository, by default the official
-GNU@tie{}Guix repository, though this can be customized.
+GNU@tie{}Guix repository, though this can be customized. @command{guix
+pull} ensures that the code it downloads is @emph{authentic} by
+verifying that commits are signed by Guix developers.
Specifically, @command{guix pull} downloads code from the @dfn{channels}
(@pxref{Channels}) specified by one of the followings, in this order:
diff --git a/guix/channels.scm b/guix/channels.scm
index 84c47fc0d0..c2ea0e26ff 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -21,6 +21,11 @@
(define-module (guix channels)
#:use-module (git)
#:use-module (guix git)
+ #:use-module (guix git-authenticate)
+ #:use-module ((guix openpgp)
+ #:select (openpgp-public-key-fingerprint
+ openpgp-format-fingerprint))
+ #:use-module (guix base16)
#:use-module (guix records)
#:use-module (guix gexp)
#:use-module (guix modules)
@@ -28,6 +33,7 @@
#:use-module (guix monads)
#:use-module (guix profiles)
#:use-module (guix packages)
+ #:use-module (guix progress)
#:use-module (guix derivations)
#:use-module (guix combinators)
#:use-module (guix diagnostics)
@@ -48,17 +54,23 @@
#:autoload (guix self) (whole-package make-config.scm)
#:autoload (guix inferior) (gexp->derivation-in-inferior) ;FIXME: circular dep
#:autoload (guix quirks) (%quirks %patches applicable-patch? apply-patch)
+ #:use-module (ice-9 format)
#:use-module (ice-9 match)
#:use-module (ice-9 vlist)
#:use-module ((ice-9 rdelim) #:select (read-string))
+ #:use-module ((rnrs bytevectors) #:select (bytevector=?))
#:export (channel
channel?
channel-name
channel-url
channel-branch
channel-commit
+ channel-introduction
channel-location
+ channel-introduction?
+ ;; <channel-introduction> accessors purposefully omitted for now.
+
%default-channels
guix-channel?
@@ -67,6 +79,7 @@
channel-instance-commit
channel-instance-checkout
+ authenticate-channel
latest-channel-instances
checkout->channel-instance
latest-channel-derivation
@@ -104,15 +117,44 @@
(url channel-url)
(branch channel-branch (default "master"))
(commit channel-commit (default #f))
+ (introduction channel-introduction (default #f))
(location channel-location
(default (current-source-location)) (innate)))
+;; Channel introductions. A "channel introduction" provides a commit/signer
+;; pair that specifies the first commit of the authentication process as well
+;; as its signer's fingerprint. The pair must be signed by the signer of that
+;; commit so that only them may emit this introduction. Introductions are
+;; used to bootstrap trust in a channel.
+(define-record-type <channel-introduction>
+ (make-channel-introduction first-signed-commit first-commit-signer
+ signature)
+ channel-introduction?
+ (first-signed-commit channel-introduction-first-signed-commit) ;hex string
+ (first-commit-signer channel-introduction-first-commit-signer) ;bytevector
+ (signature channel-introduction-signature)) ;string
+
+(define %guix-channel-introduction
+ ;; Introduction of the official 'guix channel. The chosen commit is the
+ ;; first one that introduces '.guix-authorizations' on the 'core-updates'
+ ;; branch that was eventually merged in 'master'. Any branch starting
+ ;; before that commit cannot be merged or it will be rejected by 'guix pull'
+ ;; & co.
+ (make-channel-introduction
+ "87a40d7203a813921b3ef0805c2b46c0026d6c31"
+ (base16-string->bytevector
+ (string-downcase
+ (string-filter char-set:hex-digit ;mbakke
+ "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")))
+ #f)) ;TODO: Add an intro signature so it can be exported.
+
(define %default-channels
;; Default list of channels.
(list (channel
(name 'guix)
(branch "master")
- (url "https://git.savannah.gnu.org/git/guix.git"))))
+ (url "https://git.savannah.gnu.org/git/guix.git")
+ (introduction %guix-channel-introduction))))
(define (guix-channel? channel)
"Return true if CHANNEL is the 'guix' channel."
@@ -126,11 +168,16 @@
(checkout channel-instance-checkout))
(define-record-type <channel-metadata>
- (channel-metadata directory dependencies news-file)
+ (channel-metadata directory dependencies news-file keyring-reference)
channel-metadata?
(directory channel-metadata-directory) ;string with leading slash
(dependencies channel-metadata-dependencies) ;list of <channel>
- (news-file channel-metadata-news-file)) ;string | #f
+ (news-file channel-metadata-news-file) ;string | #f
+ (keyring-reference channel-metadata-keyring-reference)) ;string
+
+(define %default-keyring-reference
+ ;; Default value of the 'keyring-reference' field.
+ "keyring")
(define (channel-reference channel)
"Return the \"reference\" for CHANNEL, an sexp suitable for
@@ -147,7 +194,10 @@ if valid metadata could not be read from PORT."
(('channel ('version 0) properties ...)
(let ((directory (and=> (assoc-ref properties 'directory) first))
(dependencies (or (assoc-ref properties 'dependencies) '()))
- (news-file (and=> (assoc-ref properties 'news-file) first)))
+ (news-file (and=> (assoc-ref properties 'news-file) first))
+ (keyring-reference
+ (or (and=> (assoc-ref properties 'keyring-reference) first)
+ %default-keyring-reference)))
(channel-metadata
(cond ((not directory) "/") ;directory
((string-prefix? "/" directory) directory)
@@ -164,7 +214,8 @@ if valid metadata could not be read from PORT."
(url url)
(commit (get 'commit))))))
dependencies)
- news-file))) ;news-file
+ news-file
+ keyring-reference)))
((and ('channel ('version version) _ ...) sexp)
(raise (condition
(&message (message "unsupported '.guix-channel' version"))
@@ -188,7 +239,7 @@ doesn't exist."
read-channel-metadata))
(lambda args
(if (= ENOENT (system-error-errno args))
- (channel-metadata "/" '() #f)
+ (channel-metadata "/" '() #f %default-keyring-reference)
(apply throw args)))))
(define (channel-instance-metadata instance)
@@ -212,6 +263,117 @@ result is unspecified."
(apply-patch patch checkout))
(loop rest)))))
+(define commit-short-id
+ (compose (cut string-take <> 7) oid->string commit-id))
+
+(define (verify-introductory-commit repository introduction keyring)
+ "Raise an exception if the first commit described in INTRODUCTION doesn't
+have the expected signer."
+ (define commit-id
+ (channel-introduction-first-signed-commit introduction))
+
+ (define actual-signer
+ (openpgp-public-key-fingerprint
+ (commit-signing-key repository (string->oid commit-id)
+ keyring)))
+
+ (define expected-signer
+ (channel-introduction-first-commit-signer introduction))
+
+ (unless (bytevector=? expected-signer actual-signer)
+ (raise (condition
+ (&message
+ (message (format #f (G_ "initial commit ~a is signed by '~a' \
+instead of '~a'")
+ commit-id
+ (openpgp-format-fingerprint actual-signer)
+ (openpgp-format-fingerprint expected-signer))))))))
+
+(define* (authenticate-channel channel checkout commit
+ #:key (keyring-reference-prefix "origin/"))
+ "Authenticate the given COMMIT of CHANNEL, available at CHECKOUT, a
+directory containing a CHANNEL checkout. Raise an error if authentication
+fails."
+ ;; XXX: Too bad we need to re-open CHECKOUT.
+ (with-repository checkout repository
+ (define start-commit
+ (commit-lookup repository
+ (string->oid
+ (channel-introduction-first-signed-commit
+ (channel-introduction channel)))))
+
+ (define end-commit
+ (commit-lookup repository (string->oid commit)))
+
+ (define cache-key
+ (string-append "channels/" (symbol->string (channel-name channel))))
+
+ (define keyring-reference
+ (channel-metadata-keyring-reference
+ (read-channel-metadata-from-source checkout)))
+
+ (define keyring
+ (load-keyring-from-reference repository
+ (string-append keyring-reference-prefix
+ keyring-reference)))
+
+ (define authenticated-commits
+ ;; Previously-authenticated commits that don't need to be checked again.
+ (filter-map (lambda (id)
+ (false-if-exception
+ (commit-lookup repository (string->oid id))))
+ (previously-authenticated-commits cache-key)))
+
+ (define commits
+ ;; Commits to authenticate, excluding the closure of
+ ;; AUTHENTICATED-COMMITS.
+ (commit-difference end-commit start-commit
+ authenticated-commits))
+
+ (define reporter
+ (progress-reporter/bar (length commits)))
+
+ ;; When COMMITS is empty, it's either because AUTHENTICATED-COMMITS
+ ;; contains END-COMMIT or because END-COMMIT is not a descendant of
+ ;; START-COMMIT. Check that.
+ (if (null? commits)
+ (match (commit-relation start-commit end-commit)
+ ((or 'self 'ancestor 'descendant) #t) ;nothing to do!
+ ('unrelated
+ (raise
+ (condition
+ (&message
+ (message
+ (format #f (G_ "'~a' is not related to introductory \
+commit of channel '~a'~%")
+ (oid->string (commit-id end-commit))
+ (channel-name channel))))))))
+ (begin
+ (format (current-error-port)
+ (G_ "Authenticating channel '~a', \
+commits ~a to ~a (~h new commits)...~%")
+ (channel-name channel)
+ (commit-short-id start-commit)
+ (commit-short-id end-commit)
+ (length commits))
+
+ ;; If it's our first time, verify CHANNEL's introductory commit.
+ (when (null? authenticated-commits)
+ (verify-introductory-commit repository
+ (channel-introduction channel)
+ keyring))
+
+ (call-with-progress-reporter reporter
+ (lambda (report)
+ (authenticate-commits repository commits
+ #:keyring keyring
+ #:report-progress report)))
+
+ (unless (null? commits)
+ (cache-authenticated-commit cache-key
+ (oid->string
+ (commit-id end-commit))))))))
+
(define* (latest-channel-instance store channel
#:key (patches %patches)
starting-commit)
@@ -225,6 +387,14 @@ relation to STARTING-COMMIT when provided."
(update-cached-checkout (channel-url channel)
#:ref (channel-reference channel)
#:starting-commit starting-commit)))
+ (if (channel-introduction channel)
+ (authenticate-channel channel checkout commit)
+ ;; TODO: Warn for all the channels once the authentication interface
+ ;; is public.
+ (when (guix-channel? channel)
+ (warning (G_ "the code of channel '~a' cannot be authenticated~%")
+ (channel-name channel))))
+
(when (guix-channel? channel)
;; Apply the relevant subset of PATCHES directly in CHECKOUT. This is
;; safe to do because 'switch-to-ref' eventually does a hard reset.
diff --git a/tests/channels.scm b/tests/channels.scm
index 3b141428c8..2c857083e9 100644
--- a/tests/channels.scm
+++ b/tests/channels.scm
@@ -31,15 +31,28 @@
#:use-module ((guix build utils) #:select (which))
#:use-module (git)
#:use-module (guix git)
+ #:use-module (guix git-authenticate)
+ #:use-module (guix openpgp)
#:use-module (guix tests git)
+ #:use-module (guix tests gnupg)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-26)
#:use-module (srfi srfi-34)
#:use-module (srfi srfi-35)
#:use-module (srfi srfi-64)
+ #:use-module (rnrs bytevectors)
+ #:use-module (rnrs io ports)
#:use-module (ice-9 control)
#:use-module (ice-9 match))
+(define (gpg+git-available?)
+ (and (which (git-command))
+ (which (gpg-command)) (which (gpgconf-command))))
+
+(define commit-id-string
+ (compose oid->string commit-id))
+
+
(test-begin "channels")
(define* (make-instance #:key
@@ -389,4 +402,113 @@
(channel-news-for-commit channel commit5 commit1))
'(#f "tag-for-first-news-entry")))))))
+(unless (gpg+git-available?) (test-skip 1))
+(test-assert "authenticate-channel, wrong first commit signer"
+ (with-fresh-gnupg-setup (list %ed25519-public-key-file
+ %ed25519-secret-key-file
+ %ed25519bis-public-key-file
+ %ed25519bis-secret-key-file)
+ (with-temporary-git-repository directory
+ `((add ".guix-channel"
+ ,(object->string
+ '(channel (version 0)
+ (keyring-reference "master"))))
+ (add ".guix-authorizations"
+ ,(object->string
+ `(authorizations (version 0)
+ ((,(key-fingerprint
+ %ed25519-public-key-file)
+ (name "Charlie"))))))
+ (add "signer.key" ,(call-with-input-file %ed25519-public-key-file
+ get-string-all))
+ (commit "first commit"
+ (signer ,(key-fingerprint %ed25519-public-key-file))))
+ (with-repository directory repository
+ (let* ((commit1 (find-commit repository "first"))
+ (intro ((@@ (guix channels) make-channel-introduction)
+ (commit-id-string commit1)
+ (openpgp-public-key-fingerprint
+ (read-openpgp-packet
+ %ed25519bis-public-key-file)) ;different key
+ #f)) ;no signature
+ (channel (channel (name 'example)
+ (url (string-append "file://" directory))
+ (introduction intro))))
+ (guard (c ((message? c)
+ (->bool (string-contains (condition-message c)
+ "initial commit"))))
+ (authenticate-channel channel directory
+ (commit-id-string commit1)
+ #:keyring-reference-prefix "")
+ 'failed))))))
+
+(unless (gpg+git-available?) (test-skip 1))
+(test-assert "authenticate-channel, .guix-authorizations"
+ (with-fresh-gnupg-setup (list %ed25519-public-key-file
+ %ed25519-secret-key-file
+ %ed25519bis-public-key-file
+ %ed25519bis-secret-key-file)
+ (with-temporary-git-repository directory
+ `((add ".guix-channel"
+ ,(object->string
+ '(channel (version 0)
+ (keyring-reference "channel-keyring"))))
+ (add ".guix-authorizations"
+ ,(object->string
+ `(authorizations (version 0)
+ ((,(key-fingerprint
+ %ed25519-public-key-file)
+ (name "Charlie"))))))
+ (commit "zeroth commit")
+ (add "a.txt" "A")
+ (commit "first commit"
+ (signer ,(key-fingerprint %ed25519-public-key-file)))
+ (add "b.txt" "B")
+ (commit "second commit"
+ (signer ,(key-fingerprint %ed25519-public-key-file)))
+ (add "c.txt" "C")
+ (commit "third commit"
+ (signer ,(key-fingerprint %ed25519bis-public-key-file)))
+ (branch "channel-keyring")
+ (checkout "channel-keyring")
+ (add "signer.key" ,(call-with-input-file %ed25519-public-key-file
+ get-string-all))
+ (add "other.key" ,(call-with-input-file %ed25519bis-public-key-file
+ get-string-all))
+ (commit "keyring commit")
+ (checkout "master"))
+ (with-repository directory repository
+ (let* ((commit1 (find-commit repository "first"))
+ (commit2 (find-commit repository "second"))
+ (commit3 (find-commit repository "third"))
+ (intro ((@@ (guix channels) make-channel-introduction)
+ (commit-id-string commit1)
+ (openpgp-public-key-fingerprint
+ (read-openpgp-packet
+ %ed25519-public-key-file))
+ #f)) ;no signature
+ (channel (channel (name 'example)
+ (url (string-append "file://" directory))
+ (introduction intro))))
+ ;; COMMIT1 and COMMIT2 are fine.
+ (and (authenticate-channel channel directory
+ (commit-id-string commit2)
+ #:keyring-reference-prefix "")
+
+ ;; COMMIT3 is signed by an unauthorized key according to its
+ ;; parent's '.guix-authorizations' file.
+ (guard (c ((unauthorized-commit-error? c)
+ (and (oid=? (git-authentication-error-commit c)
+ (commit-id commit3))
+ (bytevector=?
+ (openpgp-public-key-fingerprint
+ (unauthorized-commit-error-signing-key c))
+ (openpgp-public-key-fingerprint
+ (read-openpgp-packet
+ %ed25519bis-public-key-file))))))
+ (authenticate-channel channel directory
+ (commit-id-string commit3)
+ #:keyring-reference-prefix "")
+ 'failed)))))))
+
(test-end "channels")
--
2.26.2
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 08 Jun 2020 21:55:04 GMT) (full text, mbox, link).
Message #240 received at 22883@debbugs.gnu.org (full text, mbox, reply):
This should come before patching, authentication, etc.
* guix/channels.scm (latest-channel-instance): Add #:validate-pull
parameter and honor it. Return a single value: the instance.
(ensure-forward-channel-update): Change 'instance' parameter to 'commit'
and adjust accordingly.
(latest-channel-instances): Adjust to 'latest-channel-instance' changes.
* guix/scripts/pull.scm (warn-about-backward-updates): Change 'instance'
parameter to 'commit' and adjust accordingly.
* tests/channels.scm ("latest-channel-instances #:validate-pull"):
Likewise.
---
guix/channels.scm | 37 ++++++++++++++++++++-----------------
guix/scripts/pull.scm | 10 ++++------
tests/channels.scm | 4 ++--
3 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/guix/channels.scm b/guix/channels.scm
index c2ea0e26ff..6047b51010 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -376,9 +376,12 @@ commits ~a to ~a (~h new commits)...~%")
(define* (latest-channel-instance store channel
#:key (patches %patches)
- starting-commit)
- "Return two values: the latest channel instance for CHANNEL, and its
-relation to STARTING-COMMIT when provided."
+ starting-commit
+ (validate-pull
+ ensure-forward-channel-update))
+ "Return the latest channel instance for CHANNEL. When STARTING-COMMIT is
+true, call VALIDATE-PULL with CHANNEL, STARTING-COMMIT, the target commit, and
+their relation."
(define (dot-git? file stat)
(and (string=? (basename file) ".git")
(eq? 'directory (stat:type stat))))
@@ -387,6 +390,9 @@ relation to STARTING-COMMIT when provided."
(update-cached-checkout (channel-url channel)
#:ref (channel-reference channel)
#:starting-commit starting-commit)))
+ (when relation
+ (validate-pull channel starting-commit commit relation))
+
(if (channel-introduction channel)
(authenticate-channel channel checkout commit)
;; TODO: Warn for all the channels once the authentication interface
@@ -403,12 +409,11 @@ relation to STARTING-COMMIT when provided."
(let* ((name (url+commit->name (channel-url channel) commit))
(checkout (add-to-store store name #t "sha256" checkout
#:select? (negate dot-git?))))
- (values (channel-instance channel commit checkout)
- relation))))
+ (channel-instance channel commit checkout))))
-(define (ensure-forward-channel-update channel start instance relation)
+(define (ensure-forward-channel-update channel start commit relation)
"Raise an error if RELATION is not 'ancestor, meaning that START is not an
-ancestor of the commit in INSTANCE, unless CHANNEL specifies a commit.
+ancestor of COMMIT, unless CHANNEL specifies a commit.
This procedure implements a channel update policy meant to be used as a
#:validate-pull argument."
@@ -422,8 +427,7 @@ This procedure implements a channel update policy meant to be used as a
(format #f (G_ "\
aborting update of channel '~a' to commit ~a, which is not a descendant of ~a")
(channel-name channel)
- (channel-instance-commit instance)
- start))))
+ commit start))))
;; If the user asked for a specific commit, they might want
;; that to happen nevertheless, so tell them about the
@@ -482,14 +486,13 @@ depending on the policy it implements."
(G_ "Updating channel '~a' from Git repository at '~a'...~%")
(channel-name channel)
(channel-url channel))
- (let*-values (((current)
- (current-commit (channel-name channel)))
- ((instance relation)
- (latest-channel-instance store channel
- #:starting-commit
- current)))
- (when relation
- (validate-pull channel current instance relation))
+ (let* ((current (current-commit (channel-name channel)))
+ (instance
+ (latest-channel-instance store channel
+ #:validate-pull
+ validate-pull
+ #:starting-commit
+ current)))
(let-values (((new-instances new-channels)
(loop (channel-instance-dependencies instance)
diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index c386d81b8e..d3d0d2bd64 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -195,20 +195,18 @@ Download and deploy the latest version of Guix.\n"))
%standard-build-options))
-(define (warn-about-backward-updates channel start instance relation)
- "Warn about non-forward updates of CHANNEL from START to INSTANCE, without
+(define (warn-about-backward-updates channel start commit relation)
+ "Warn about non-forward updates of CHANNEL from START to COMMIT, without
aborting."
(match relation
((or 'ancestor 'self)
#t)
('descendant
(warning (G_ "rolling back channel '~a' from ~a to ~a~%")
- (channel-name channel) start
- (channel-instance-commit instance)))
+ (channel-name channel) start commit))
('unrelated
(warning (G_ "moving channel '~a' from ~a to unrelated commit ~a~%")
- (channel-name channel) start
- (channel-instance-commit instance)))))
+ (channel-name channel) start commit))))
(define* (display-profile-news profile #:key concise?
current-is-newer?)
diff --git a/tests/channels.scm b/tests/channels.scm
index 2c857083e9..5f13a48ec1 100644
--- a/tests/channels.scm
+++ b/tests/channels.scm
@@ -212,12 +212,12 @@
(commit (oid->string (commit-id commit2)))))
(old (channel (inherit spec)
(commit (oid->string (commit-id commit1))))))
- (define (validate-pull channel current instance relation)
+ (define (validate-pull channel current commit relation)
(return (and (eq? channel old)
(string=? (oid->string (commit-id commit2))
current)
(string=? (oid->string (commit-id commit1))
- (channel-instance-commit instance))
+ commit)
relation)))
(with-store store
--
2.26.2
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 08 Jun 2020 21:55:05 GMT) (full text, mbox, link).
Message #243 received at 22883@debbugs.gnu.org (full text, mbox, reply):
* .guix-channel: Add 'keyring-reference'. --- .guix-channel | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.guix-channel b/.guix-channel index 3e618d79f8..f4459f1de1 100644 --- a/.guix-channel +++ b/.guix-channel @@ -2,4 +2,5 @@ (channel (version 0) - (news-file "etc/news.scm")) + (news-file "etc/news.scm") + (keyring-reference "keyring")) -- 2.26.2
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 08 Jun 2020 21:55:05 GMT) (full text, mbox, link).
Message #246 received at 22883@debbugs.gnu.org (full text, mbox, reply):
* tests/git-authenticate.scm (key-id): Remove.
(%ed25519-public-key-file, %ed25519-secret-key-file)
(%ed25519bis-public-key-file, %ed25519bis-secret-key-file)
(read-openpgp-packet, key-fingerprint): Move to...
* guix/tests/gnupg.scm: ... here.
---
guix/tests/gnupg.scm | 32 +++++++++++++++++++++++++++++++-
tests/git-authenticate.scm | 25 -------------------------
2 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/guix/tests/gnupg.scm b/guix/tests/gnupg.scm
index 47c858d232..eb8ff63a43 100644
--- a/guix/tests/gnupg.scm
+++ b/guix/tests/gnupg.scm
@@ -17,12 +17,23 @@
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
(define-module (guix tests gnupg)
+ #:use-module (guix openpgp)
#:use-module (guix utils)
#:use-module (guix build utils)
+ #:use-module (rnrs io ports)
#:use-module (ice-9 match)
#:export (gpg-command
gpgconf-command
- with-fresh-gnupg-setup))
+ with-fresh-gnupg-setup
+
+ %ed25519-public-key-file
+ %ed25519-secret-key-file
+ %ed25519bis-public-key-file
+ %ed25519bis-secret-key-file
+
+ read-openpgp-packet
+ key-fingerprint
+ key-id))
(define gpg-command
(make-parameter "gpg"))
@@ -50,3 +61,22 @@ listed in IMPORTED, and only them, have been imported. This sets 'GNUPGHOME'
such that the user's real GnuPG files are left untouched. The 'gpg-agent'
process is terminated afterwards."
(call-with-fresh-gnupg-setup imported (lambda () exp ...)))
+
+(define %ed25519-public-key-file
+ (search-path %load-path "tests/ed25519.key"))
+(define %ed25519-secret-key-file
+ (search-path %load-path "tests/ed25519.sec"))
+(define %ed25519bis-public-key-file
+ (search-path %load-path "tests/ed25519bis.key"))
+(define %ed25519bis-secret-key-file
+ (search-path %load-path "tests/ed25519bis.sec"))
+
+(define (read-openpgp-packet file)
+ (get-openpgp-packet
+ (open-bytevector-input-port
+ (call-with-input-file file read-radix-64))))
+
+(define key-fingerprint
+ (compose openpgp-format-fingerprint
+ openpgp-public-key-fingerprint
+ read-openpgp-packet))
diff --git a/tests/git-authenticate.scm b/tests/git-authenticate.scm
index 84689d628e..d713fa6a22 100644
--- a/tests/git-authenticate.scm
+++ b/tests/git-authenticate.scm
@@ -32,31 +32,6 @@
;; Test the (guix git-authenticate) tools.
-(define %ed25519-public-key-file
- (search-path %load-path "tests/ed25519.key"))
-(define %ed25519-secret-key-file
- (search-path %load-path "tests/ed25519.sec"))
-(define %ed25519bis-public-key-file
- (search-path %load-path "tests/ed25519bis.key"))
-(define %ed25519bis-secret-key-file
- (search-path %load-path "tests/ed25519bis.sec"))
-
-(define (read-openpgp-packet file)
- (get-openpgp-packet
- (open-bytevector-input-port
- (call-with-input-file file read-radix-64))))
-
-(define key-fingerprint
- (compose openpgp-format-fingerprint
- openpgp-public-key-fingerprint
- read-openpgp-packet))
-
-(define (key-id file)
- (define id
- (openpgp-public-key-id (read-openpgp-packet)))
-
- (string-pad (number->string id 16) 16 #\0))
-
(define (gpg+git-available?)
(and (which (git-command))
(which (gpg-command)) (which (gpgconf-command))))
--
2.26.2
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 08 Jun 2020 21:55:05 GMT) (full text, mbox, link).
Message #249 received at 22883@debbugs.gnu.org (full text, mbox, reply):
This is useful when people run "guix time-machine -C channels.scm",
where 'channels.scm' misses channel introductions.
* guix/channels.scm (%default-channel-url): New variable.
(%default-channels): Use it.
(ensure-default-introduction): New procedure.
(latest-channel-instance): Call it.
---
guix/channels.scm | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/guix/channels.scm b/guix/channels.scm
index 6047b51010..43ddff6f7c 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -148,18 +148,32 @@
"BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")))
#f)) ;TODO: Add an intro signature so it can be exported.
+(define %default-channel-url
+ ;; URL of the default 'guix' channel.
+ "https://git.savannah.gnu.org/git/guix.git")
+
(define %default-channels
;; Default list of channels.
(list (channel
(name 'guix)
(branch "master")
- (url "https://git.savannah.gnu.org/git/guix.git")
+ (url %default-channel-url)
(introduction %guix-channel-introduction))))
(define (guix-channel? channel)
"Return true if CHANNEL is the 'guix' channel."
(eq? 'guix (channel-name channel)))
+(define (ensure-default-introduction chan)
+ "If CHAN represents the \"official\" 'guix' channel and lacks an
+introduction, add it."
+ (if (and (guix-channel? chan)
+ (not (channel-introduction chan))
+ (string=? (channel-url chan) %default-channel-url))
+ (channel (inherit chan)
+ (introduction %guix-channel-introduction))
+ chan))
+
(define-record-type <channel-instance>
(channel-instance channel commit checkout)
channel-instance?
@@ -386,7 +400,9 @@ their relation."
(and (string=? (basename file) ".git")
(eq? 'directory (stat:type stat))))
- (let-values (((checkout commit relation)
+ (let-values (((channel)
+ (ensure-default-introduction channel))
+ ((checkout commit relation)
(update-cached-checkout (channel-url channel)
#:ref (channel-reference channel)
#:starting-commit starting-commit)))
--
2.26.2
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 08 Jun 2020 21:55:06 GMT) (full text, mbox, link).
Message #252 received at 22883@debbugs.gnu.org (full text, mbox, reply):
* guix/channels.scm (latest-channel-instance): Add #:authenticate? and
honor it.
(latest-channel-instances): Likewise.
* guix/scripts/pull.scm (%default-options): Add 'authenticate-channels?'.
(show-help, %options): Add '--disable-authentication'.
(guix-pull): Pass #:authenticate? to 'latest-channel-instances'.
* doc/guix.texi (Invoking guix pull): Document it.
---
doc/guix.texi | 14 ++++++++++++++
guix/channels.scm | 25 +++++++++++++++++--------
guix/scripts/pull.scm | 14 ++++++++++++--
3 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/doc/guix.texi b/doc/guix.texi
index 6fcb47970b..8131b3bf0d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -3927,6 +3927,20 @@ Make sure you understand its security implications before using
@option{--allow-downgrades}.
@end quotation
+@item --disable-authentication
+Allow pulling channel code without authenticating it.
+
+@cindex authentication, of channel code
+By default, @command{guix pull} authenticates code downloaded from
+channels by verifying that its commits are signed by authorized
+developers, and raises an error if this is not the case. This option
+instructs it to not perform any such verification.
+
+@quotation Note
+Make sure you understand its security implications before using
+@option{--disable-authentication}.
+@end quotation
+
@item --system=@var{system}
@itemx -s @var{system}
Attempt to build for @var{system}---e.g., @code{i686-linux}---instead of
diff --git a/guix/channels.scm b/guix/channels.scm
index 43ddff6f7c..9e6adda5e9 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -391,11 +391,12 @@ commits ~a to ~a (~h new commits)...~%")
(define* (latest-channel-instance store channel
#:key (patches %patches)
starting-commit
+ (authenticate? #f)
(validate-pull
ensure-forward-channel-update))
"Return the latest channel instance for CHANNEL. When STARTING-COMMIT is
true, call VALIDATE-PULL with CHANNEL, STARTING-COMMIT, the target commit, and
-their relation."
+their relation. When AUTHENTICATE? is false, CHANNEL is not authenticated."
(define (dot-git? file stat)
(and (string=? (basename file) ".git")
(eq? 'directory (stat:type stat))))
@@ -409,13 +410,15 @@ their relation."
(when relation
(validate-pull channel starting-commit commit relation))
- (if (channel-introduction channel)
- (authenticate-channel channel checkout commit)
- ;; TODO: Warn for all the channels once the authentication interface
- ;; is public.
- (when (guix-channel? channel)
- (warning (G_ "the code of channel '~a' cannot be authenticated~%")
- (channel-name channel))))
+ (if authenticate?
+ (if (channel-introduction channel)
+ (authenticate-channel channel checkout commit)
+ ;; TODO: Warn for all the channels once the authentication interface
+ ;; is public.
+ (when (guix-channel? channel)
+ (warning (G_ "the code of channel '~a' cannot be authenticated~%")
+ (channel-name channel))))
+ (warning (G_ "channel authentication disabled~%")))
(when (guix-channel? channel)
;; Apply the relevant subset of PATCHES directly in CHECKOUT. This is
@@ -463,11 +466,15 @@ allow non-forward updates."))))))))))
(define* (latest-channel-instances store channels
#:key
(current-channels '())
+ (authenticate? #t)
(validate-pull
ensure-forward-channel-update))
"Return a list of channel instances corresponding to the latest checkouts of
CHANNELS and the channels on which they depend.
+When AUTHENTICATE? is true, authenticate the subset of CHANNELS that has a
+\"channel introduction\".
+
CURRENT-CHANNELS is the list of currently used channels. It is compared
against the newly-fetched instances of CHANNELS, and VALIDATE-PULL is called
for each channel update and can choose to emit warnings or raise an error,
@@ -505,6 +512,8 @@ depending on the policy it implements."
(let* ((current (current-commit (channel-name channel)))
(instance
(latest-channel-instance store channel
+ #:authenticate?
+ authenticate?
#:validate-pull
validate-pull
#:starting-commit
diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index d3d0d2bd64..f953957161 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -82,6 +82,7 @@
(graft? . #t)
(debug . 0)
(verbosity . 1)
+ (authenticate-channels? . #t)
(validate-pull . ,ensure-forward-channel-update)))
(define (show-help)
@@ -97,6 +98,9 @@ Download and deploy the latest version of Guix.\n"))
--branch=BRANCH download the tip of the specified BRANCH"))
(display (G_ "
--allow-downgrades allow downgrades to earlier channel revisions"))
+ (display (G_ "
+ --disable-authentication
+ disable channel authentication"))
(display (G_ "
-N, --news display news compared to the previous generation"))
(display (G_ "
@@ -165,6 +169,9 @@ Download and deploy the latest version of Guix.\n"))
(lambda (opt name arg result)
(alist-cons 'validate-pull warn-about-backward-updates
result)))
+ (option '("disable-authentication") #f #f
+ (lambda (opt name arg result)
+ (alist-cons 'authenticate-channels? #f result)))
(option '(#\p "profile") #t #f
(lambda (opt name arg result)
(alist-cons 'profile (canonicalize-profile arg)
@@ -771,7 +778,8 @@ Use '~/.config/guix/channels.scm' instead."))
(channels (channel-list opts))
(profile (or (assoc-ref opts 'profile) %current-profile))
(current-channels (profile-channels profile))
- (validate-pull (assoc-ref opts 'validate-pull)))
+ (validate-pull (assoc-ref opts 'validate-pull))
+ (authenticate? (assoc-ref opts 'authenticate-channels?)))
(cond ((assoc-ref opts 'query)
(process-query opts profile))
((assoc-ref opts 'generation)
@@ -793,7 +801,9 @@ Use '~/.config/guix/channels.scm' instead."))
#:current-channels
current-channels
#:validate-pull
- validate-pull)))
+ validate-pull
+ #:authenticate?
+ authenticate?)))
(format (current-error-port)
(N_ "Building from this channel:~%"
"Building from these channels:~%"
--
2.26.2
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 08 Jun 2020 21:55:06 GMT) (full text, mbox, link).
Message #255 received at 22883@debbugs.gnu.org (full text, mbox, reply):
This allows users to authenticate commits that were made before
'.guix-authorizations' was introduced.
* guix/channels.scm (<channel-introduction>)[prehistorical-authorizations]:
New field.
(%guix-historical-committers): New variable.
(openpgp-fingerprint->bytevector): New procedure.
(%guix-channel-introduction): Add 'prehistorical-authorizations' field.
(authenticate-channel): Honor it. Pass it as #:default-authorizations
to 'authenticate-commits'.
* build-aux/git-authenticate.scm (%historical-committers)
(%historical-authorized-signing-keys, commit-short-id): Remove.
* build-aux/git-authenticate.scm (git-authenticate): Rewrite to use
'authenticate-channel'.
* tests/channels.scm ("authenticate-channel, wrong first commit signer")
("authenticate-channel, .guix-authorizations"): Adjust accordingly.
---
build-aux/git-authenticate.scm | 247 ++-------------------------------
guix/channels.scm | 213 ++++++++++++++++++++++++++--
tests/channels.scm | 2 +
3 files changed, 214 insertions(+), 248 deletions(-)
diff --git a/build-aux/git-authenticate.scm b/build-aux/git-authenticate.scm
index a3d4b40ccf..a84b79dfe7 100644
--- a/build-aux/git-authenticate.scm
+++ b/build-aux/git-authenticate.scm
@@ -25,6 +25,7 @@
(guix base16)
(guix git)
(guix git-authenticate)
+ (guix channels)
(guix i18n)
((guix openpgp)
#:select (openpgp-public-key-fingerprint
@@ -37,186 +38,6 @@
(ice-9 pretty-print))
-(define %historical-committers
- ;; List of "historical" committers---people once authorized committers
- ;; before the '.guix-authorizations' file was created.
- ;;
- ;; These are the user names found on
- ;; <https://savannah.gnu.org/project/memberlist.php?group=guix> along with
- ;; the fingerprint of the signing (sub)key.
- '(("andreas"
- "AD17 A21E F8AE D8F1 CC02 DBD9 F7D5 C9BF 765C 61E3")
- ("ajgrf"
- "2A39 3FFF 68F4 EF7A 3D29 12AF 6F51 20A0 22FB B2D5")
- ("alexvong1995"
- "306F CB8F 2C01 C25D 29D3 0556 61EF 502E F602 52F2")
- ("alezost"
- "4FB9 9F49 2B12 A365 7997 E664 8246 0C08 2A0E E98F")
- ("ambrevar"
- "50F3 3E2E 5B0C 3D90 0424 ABE8 9BDC F497 A4BB CC7F")
- ("apteryx"
- "27D5 86A4 F890 0854 329F F09F 1260 E464 82E6 3562")
- ("arunisaac"
- "7F73 0343 F2F0 9F3C 77BF 79D3 2E25 EE8B 6180 2BB3")
- ("atheia"
- ;; primary: "3B12 9196 AE30 0C3C 0E90 A26F A715 5567 3271 9948"
- "9A2B 401E D001 0650 1584 BAAC 8BC4 F447 6E8A 8E00")
- ("bandali"
- ;; primary: "BE62 7373 8E61 6D6D 1B3A 08E8 A21A 0202 4881 6103"
- "39B3 3C8D 9448 0D2D DCC2 A498 8B44 A0CD C7B9 56F2")
- ("bavier"
- ;; primary: "34FF 38BC D151 25A6 E340 A0B5 3453 2F9F AFCA 8B8E"
- "A0C5 E352 2EF8 EF5C 64CD B7F0 FD73 CAC7 19D3 2566")
- ("beffa"
- "3774 8024 880F D3FF DCA2 C9AB 5893 6E0E 2F1B 5A4C")
- ("benwoodcroft"
- "BCF8 F737 2CED 080A 67EB 592D 2A6A D9F4 AAC2 0DF6")
- ("biscuolo"
- "45CC 63B8 5258 C9D5 5F34 B239 D37D 0EA7 CECC 3912")
- ("boskovits"
- "7988 3B9F 7D6A 4DBF 3719 0367 2506 A96C CF63 0B21")
- ("brettgilio"
- "DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE")
- ("carl"
- ;; primary: "0401 7A2A 6D9A 0CCD C81D 8EC2 96AB 007F 1A7E D999"
- "09CD D25B 5244 A376 78F6 EEA8 0CC5 2153 1979 91A5")
- ("cbaines"
- "3E89 EEE7 458E 720D 9754 E0B2 5E28 A33B 0B84 F577")
- ("civodul"
- "3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5")
- ("cwebber"
- "510A 8628 E2A7 7678 8F8C 709C 4BC0 2592 5FF8 F4D3")
- ("dannym"
- ;; primary: "295A F991 6F46 F8A1 34B0 29DA 8086 3842 F0FE D83B"
- "76CE C6B1 7274 B465 C02D B3D9 E71A 3554 2C30 BAA5")
- ("davexunit"
- "B3C0 DB4D AD73 BA5D 285E 19AE 5143 0234 CEFD 87C3")
- ("davexunit (2nd)" ;FIXME: to be confirmed!
- "8CCB A7F5 52B9 CBEA E1FB 2915 8328 C747 0FF1 D807")
- ("daviwil"
- "53C4 1E6E 41AA FE55 335A CA5E 446A 2ED4 D940 BF14")
- ("dvc"
- "6909 6DFD D702 8BED ACC5 884B C5E0 51C7 9C0B ECDB")
- ("dvc (old)"
- "5F43 B681 0437 2F4B A898 A64B 33B9 E9FD E28D 2C23")
- ("efraim"
- "A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351")
- ("efraim (old)"
- "9157 41FE B22F A4E3 3B6E 8F8D F4C1 D391 7EAC EE93")
- ("glv"
- ;; primary: "2453 02B1 BAB1 F867 FDCA 96BC 8F3F 861F 82EB 7A9A"
- "CBC5 9C66 EC27 B971 7940 6B3E 6BE8 208A DF21 FE3F")
- ("hoebjo"
- "2219 43F4 9E9F 276F 9499 3382 BF28 6CB6 593E 5FFD")
- ("htgoebel"
- "B943 509D 633E 80DD 27FC 4EED 634A 8DFF D3F6 31DF")
- ("ipetkov"
- "7440 26BA 7CA3 C668 E940 1D53 0B43 1E98 3705 6942")
- ("iyzsong"
- ;; primary: "66A5 6D9C 9A98 BE7F 719A B401 2652 5665 AE72 7D37"
- "0325 78A6 8298 94E7 2AA2 66F5 D415 BF25 3B51 5976")
-
- ;; https://lists.gnu.org/archive/html/guix-devel/2018-04/msg00229.html
- ("janneke (old)"
- "DB34 CB51 D25C 9408 156F CDD6 A12F 8797 8D70 1B99")
- ("janneke"
- "1A85 8392 E331 EAFD B8C2 7FFB F3C1 A0D9 C1D6 5273")
-
- ("jlicht"
- ;; primary: "1BA4 08C5 8BF2 0EA7 3179 635A 865D C0A3 DED9 B5D0"
- "E31D 9DDE EBA5 4A14 8A20 4550 DA45 97F9 47B4 1025")
- ("jmd"
- "8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3")
- ("kkebreau"
- "83B6 703A DCCA 3B69 4BCE 2DA6 E6A5 EE3C 1946 7A0D")
- ("leungbk"
- "45E5 75FA 53EA 8BD6 1BCE 0B4E 3ADC 75F0 13D6 78F9")
- ("lfam"
- ;; primary: "4F71 6F9A 8FA2 C80E F1B5 E1BA 5E35 F231 DE1A C5E0"
- "B051 5948 F1E7 D3C1 B980 38A0 2646 FA30 BACA 7F08")
- ("lsl88"
- "2AE3 1395 932B E642 FC0E D99C 9BED 6EDA 32E5 B0BC")
- ("marusich"
- "CBF5 9755 CBE7 E7EF EF18 3FB1 DD40 9A15 D822 469D")
- ("mbakke"
- "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")
- ("mhw"
- "D919 0965 CE03 199E AF28 B3BE 7CEF 2984 7562 C516")
- ("mothacehe"
- "4008 6A7E 0252 9B60 31FB 8607 8354 7635 3176 9CA6")
- ("mthl"
- "F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37")
- ("nckx"
- ;; primary: "F5BC 5534 C36F 0087 B39D 36EF 1C9D C4FE B9DB 7C4B"
- "F5DA 2032 4B87 3D0B 7A38 7672 0DB0 FF88 4F55 6D79")
- ("nckx (revoked; not compromised)"
- ;; primary: "F5BC 5534 C36F 0087 B39D 36EF 1C9D C4FE B9DB 7C4B"
- "7E8F AED0 0944 78EF 72E6 4D16 D889 B0F0 18C5 493C")
- ("niedzejkob"
- "E576 BFB2 CF6E B13D F571 33B9 E315 A758 4613 1564")
- ("ngz"
- "ED0E F1C8 E126 BA83 1B48 5FE9 DA00 B4F0 48E9 2F2D")
- ("pelzflorian"
- "CEF4 CB91 4856 BA38 0A20 A7E2 3008 88CB 39C6 3817")
- ("pgarlick"
- ;; primary: "B68B DF22 73F9 DA0E 63C1 8A32 515B F416 9242 D600"
- "C699 ED09 E51B CE89 FD1D A078 AAC7 E891 896B 568A")
- ("phant0mas"
- "3A86 380E 58A8 B942 8D39 60E1 327C 1EF3 8DF5 4C32")
- ("reepca"
- "74D6 A930 F44B 9B84 9EA5 5606 C166 AA49 5F7F 189C")
- ("rekado"
- "BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC")
- ("rhelling"
- "0154 E1B9 1CC9 D9EF 7764 8DE7 F3A7 27DB 44FC CA36")
- ("roelj (old)"
- "17CB 2812 EB63 3DFF 2C7F 0452 C3EC 1DCA 8430 72E1")
- ("roelj"
- ;; From commit cc51c03ff867d4633505354819c6d88af88bf919 (March 2020).
- ;; See <https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00070.html>.
- "F556 FD94 FB8F 8B87 79E3 6832 CBD0 CD51 38C1 9AFC")
- ("roptat (old)"
- "B5FA E628 5B41 3728 B2A0 FAED 4311 1F45 2008 6A0C")
- ("roptat"
- ;; From commit 2cbede5935eb6a40173bbdf30a9ad22bf7574c22 (Jan. 2020). See
- ;; <https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00499.html>.
- "1EFB 0909 1F17 D28C CBF9 B13A 53D4 57B2 D636 EE82")
- ("samplet"
- ;; primary: "D6B0 C593 DA8C 5EDC A44C 7A58 C336 91F7 1188 B004"
- "A02C 2D82 0EF4 B25B A6B5 1D90 2AC6 A5EC 1C35 7C59")
- ("sleep_walker"
- "77DD AD2D 97F5 31BB C0F3 C7FD DFB5 EB09 AA62 5423")
- ("snape"
- "F494 72F4 7A59 00D5 C235 F212 89F9 6D48 08F3 59C7")
- ("steap"
- "4E26 CCE9 578E 0828 9855 BDD4 1C79 95D2 D5A3 8336")
- ("taylanub"
- "9ADE 9ECF 2B19 C180 9C99 5CEA A1F4 CFCC 5283 6BAC")
-
- ;; https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00826.html
- ("thomasd"
- ;; primary: "1DD1 681F E285 E07F 11DC 0C59 2E15 A6BC D77D 54FD"
- "3D2C DA58 819C 08C2 A649 D43D 5C3B 064C 724A 5726")
- ("thomasd (old)"
- "A5C5 92EA 606E 7106 A6A3 BC08 98B2 1575 91E1 2B08")
-
- ("toothbrush"
- "D712 1D73 A40A 7264 9E43 ED7D F284 6B1A 0D32 C442")
- ("vagrantc"
- "6580 7361 3BFC C5C7 E2E4 5D45 DC51 8FC8 7F97 16AA")
- ("wigust"
- ;; primary: "C955 CC5D C048 7FB1 7966 40A9 199A F6A3 67E9 4ABB"
- "7238 7123 8EAC EB63 4548 5857 167F 8EA5 001A FA9C")
- ("wingo"
- "FF47 8FB2 64DE 32EC 2967 25A3 DDC0 F535 8812 F8F2")))
-
-(define %historical-authorized-signing-keys
- ;; Fingerprint of historically authorized signing keys.
- (map (match-lambda
- ((name fingerprint)
- (base16-string->bytevector
- (string-downcase (string-filter char-set:graphic fingerprint)))))
- %historical-committers))
(define %commits-with-bad-signature
;; Commits with a known-bad signature.
@@ -226,73 +47,25 @@
;; Commits lacking a signature.
'())
-(define commit-short-id
- (compose (cut string-take <> 7) oid->string commit-id))
-
;;;
;;; Entry point.
;;;
(define (git-authenticate args)
- (define repository
- (repository-open "."))
-
(let loop ((args args))
(match args
((_ start end)
- (define start-commit
- (commit-lookup repository (string->oid start)))
- (define end-commit
- (commit-lookup repository (string->oid end)))
-
- (define authenticated-commits
- ;; Previously-authenticated commits that don't need to be checked
- ;; again.
- (filter-map (lambda (id)
- (false-if-exception
- (commit-lookup repository (string->oid id))))
- (previously-authenticated-commits "channels/guix")))
-
- (define commits
- ;; Commits to authenticate, excluding the closure of
- ;; AUTHENTICATED-COMMITS.
- (commit-difference end-commit start-commit
- authenticated-commits))
-
- (define reporter
- (progress-reporter/bar (length commits)))
-
- (format #t (G_ "Authenticating ~a to ~a (~a commits)...~%")
- (commit-short-id start-commit)
- (commit-short-id end-commit)
- (length commits))
-
- (let ((stats (call-with-progress-reporter reporter
- (lambda (report)
- (authenticate-commits repository commits
- #:default-authorizations
- %historical-authorized-signing-keys
- #:report-progress report)))))
- (cache-authenticated-commit "channels/guix"
- (oid->string (commit-id end-commit)))
-
- (unless (null? stats)
- (format #t (G_ "Signing statistics:~%"))
- (for-each (match-lambda
- ((signer . count)
- (format #t " ~a ~10d~%"
- (openpgp-format-fingerprint
- (openpgp-public-key-fingerprint signer))
- count)))
- (sort stats
- (match-lambda*
- (((_ . count1) (_ . count2))
- (> count1 count2))))))))
+ (authenticate-channel (car %default-channels) "." end
+ ;; Require users to have a local 'keyring'
+ ;; branch.
+ #:keyring-reference-prefix ""))
((command start)
- (let* ((head (repository-head repository))
- (end (reference-target head)))
- (loop (list command start (oid->string end)))))
+ (let* ((repository (repository-open "."))
+ (head (repository-head repository))
+ (end (oid->string (reference-target head))))
+ (repository-close! repository)
+ (loop (list command start end))))
(_
(format (current-error-port)
(G_ "Usage: git-authenticate START [END]
diff --git a/guix/channels.scm b/guix/channels.scm
index 9e6adda5e9..b9983c6a43 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -126,26 +126,211 @@
;; as its signer's fingerprint. The pair must be signed by the signer of that
;; commit so that only them may emit this introduction. Introductions are
;; used to bootstrap trust in a channel.
+;;
+;; For the 'guix' channel, the introduction can also list "prehistorical
+;; authorizations": the list of fingerprints of authorized committers before
+;; the '.guix-authorizations' file was introduced. Currently this feature is
+;; only available for the 'guix' channel because otherwise we would need and
+;; out-of-band mechanism to authenticate those prehistorical authorizations.
(define-record-type <channel-introduction>
(make-channel-introduction first-signed-commit first-commit-signer
- signature)
+ prehistorical-authorizations signature)
channel-introduction?
(first-signed-commit channel-introduction-first-signed-commit) ;hex string
(first-commit-signer channel-introduction-first-commit-signer) ;bytevector
+ (prehistorical-authorizations
+ channel-introduction-prehistorical-authorizations) ;list of bytevectors
(signature channel-introduction-signature)) ;string
+(define %guix-historical-committers
+ ;; List of "historical" Guix committers---people once authorized committers
+ ;; before the '.guix-authorizations' file was created.
+ ;;
+ ;; These are the user names found on
+ ;; <https://savannah.gnu.org/project/memberlist.php?group=guix> along with
+ ;; the fingerprint of the signing (sub)key.
+ '(("andreas"
+ "AD17 A21E F8AE D8F1 CC02 DBD9 F7D5 C9BF 765C 61E3")
+ ("ajgrf"
+ "2A39 3FFF 68F4 EF7A 3D29 12AF 6F51 20A0 22FB B2D5")
+ ("alexvong1995"
+ "306F CB8F 2C01 C25D 29D3 0556 61EF 502E F602 52F2")
+ ("alezost"
+ "4FB9 9F49 2B12 A365 7997 E664 8246 0C08 2A0E E98F")
+ ("ambrevar"
+ "50F3 3E2E 5B0C 3D90 0424 ABE8 9BDC F497 A4BB CC7F")
+ ("apteryx"
+ "27D5 86A4 F890 0854 329F F09F 1260 E464 82E6 3562")
+ ("arunisaac"
+ "7F73 0343 F2F0 9F3C 77BF 79D3 2E25 EE8B 6180 2BB3")
+ ("atheia"
+ ;; primary: "3B12 9196 AE30 0C3C 0E90 A26F A715 5567 3271 9948"
+ "9A2B 401E D001 0650 1584 BAAC 8BC4 F447 6E8A 8E00")
+ ("bandali"
+ ;; primary: "BE62 7373 8E61 6D6D 1B3A 08E8 A21A 0202 4881 6103"
+ "39B3 3C8D 9448 0D2D DCC2 A498 8B44 A0CD C7B9 56F2")
+ ("bavier"
+ ;; primary: "34FF 38BC D151 25A6 E340 A0B5 3453 2F9F AFCA 8B8E"
+ "A0C5 E352 2EF8 EF5C 64CD B7F0 FD73 CAC7 19D3 2566")
+ ("beffa"
+ "3774 8024 880F D3FF DCA2 C9AB 5893 6E0E 2F1B 5A4C")
+ ("benwoodcroft"
+ "BCF8 F737 2CED 080A 67EB 592D 2A6A D9F4 AAC2 0DF6")
+ ("biscuolo"
+ "45CC 63B8 5258 C9D5 5F34 B239 D37D 0EA7 CECC 3912")
+ ("boskovits"
+ "7988 3B9F 7D6A 4DBF 3719 0367 2506 A96C CF63 0B21")
+ ("brettgilio"
+ "DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE")
+ ("carl"
+ ;; primary: "0401 7A2A 6D9A 0CCD C81D 8EC2 96AB 007F 1A7E D999"
+ "09CD D25B 5244 A376 78F6 EEA8 0CC5 2153 1979 91A5")
+ ("cbaines"
+ "3E89 EEE7 458E 720D 9754 E0B2 5E28 A33B 0B84 F577")
+ ("civodul"
+ "3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5")
+ ("cwebber"
+ "510A 8628 E2A7 7678 8F8C 709C 4BC0 2592 5FF8 F4D3")
+ ("dannym"
+ ;; primary: "295A F991 6F46 F8A1 34B0 29DA 8086 3842 F0FE D83B"
+ "76CE C6B1 7274 B465 C02D B3D9 E71A 3554 2C30 BAA5")
+ ("davexunit"
+ "B3C0 DB4D AD73 BA5D 285E 19AE 5143 0234 CEFD 87C3")
+ ("davexunit (2nd)" ;FIXME: to be confirmed!
+ "8CCB A7F5 52B9 CBEA E1FB 2915 8328 C747 0FF1 D807")
+ ("daviwil"
+ "53C4 1E6E 41AA FE55 335A CA5E 446A 2ED4 D940 BF14")
+ ("dvc"
+ "6909 6DFD D702 8BED ACC5 884B C5E0 51C7 9C0B ECDB")
+ ("dvc (old)"
+ "5F43 B681 0437 2F4B A898 A64B 33B9 E9FD E28D 2C23")
+ ("efraim"
+ "A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351")
+ ("efraim (old)"
+ "9157 41FE B22F A4E3 3B6E 8F8D F4C1 D391 7EAC EE93")
+ ("glv"
+ ;; primary: "2453 02B1 BAB1 F867 FDCA 96BC 8F3F 861F 82EB 7A9A"
+ "CBC5 9C66 EC27 B971 7940 6B3E 6BE8 208A DF21 FE3F")
+ ("hoebjo"
+ "2219 43F4 9E9F 276F 9499 3382 BF28 6CB6 593E 5FFD")
+ ("htgoebel"
+ "B943 509D 633E 80DD 27FC 4EED 634A 8DFF D3F6 31DF")
+ ("ipetkov"
+ "7440 26BA 7CA3 C668 E940 1D53 0B43 1E98 3705 6942")
+ ("iyzsong"
+ ;; primary: "66A5 6D9C 9A98 BE7F 719A B401 2652 5665 AE72 7D37"
+ "0325 78A6 8298 94E7 2AA2 66F5 D415 BF25 3B51 5976")
+
+ ;; https://lists.gnu.org/archive/html/guix-devel/2018-04/msg00229.html
+ ("janneke (old)"
+ "DB34 CB51 D25C 9408 156F CDD6 A12F 8797 8D70 1B99")
+ ("janneke"
+ "1A85 8392 E331 EAFD B8C2 7FFB F3C1 A0D9 C1D6 5273")
+
+ ("jlicht"
+ ;; primary: "1BA4 08C5 8BF2 0EA7 3179 635A 865D C0A3 DED9 B5D0"
+ "E31D 9DDE EBA5 4A14 8A20 4550 DA45 97F9 47B4 1025")
+ ("jmd"
+ "8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3")
+ ("kkebreau"
+ "83B6 703A DCCA 3B69 4BCE 2DA6 E6A5 EE3C 1946 7A0D")
+ ("leungbk"
+ "45E5 75FA 53EA 8BD6 1BCE 0B4E 3ADC 75F0 13D6 78F9")
+ ("lfam"
+ ;; primary: "4F71 6F9A 8FA2 C80E F1B5 E1BA 5E35 F231 DE1A C5E0"
+ "B051 5948 F1E7 D3C1 B980 38A0 2646 FA30 BACA 7F08")
+ ("lsl88"
+ "2AE3 1395 932B E642 FC0E D99C 9BED 6EDA 32E5 B0BC")
+ ("marusich"
+ "CBF5 9755 CBE7 E7EF EF18 3FB1 DD40 9A15 D822 469D")
+ ("mbakke"
+ "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")
+ ("mhw"
+ "D919 0965 CE03 199E AF28 B3BE 7CEF 2984 7562 C516")
+ ("mothacehe"
+ "4008 6A7E 0252 9B60 31FB 8607 8354 7635 3176 9CA6")
+ ("mthl"
+ "F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37")
+ ("nckx"
+ ;; primary: "F5BC 5534 C36F 0087 B39D 36EF 1C9D C4FE B9DB 7C4B"
+ "F5DA 2032 4B87 3D0B 7A38 7672 0DB0 FF88 4F55 6D79")
+ ("nckx (revoked; not compromised)"
+ ;; primary: "F5BC 5534 C36F 0087 B39D 36EF 1C9D C4FE B9DB 7C4B"
+ "7E8F AED0 0944 78EF 72E6 4D16 D889 B0F0 18C5 493C")
+ ("niedzejkob"
+ "E576 BFB2 CF6E B13D F571 33B9 E315 A758 4613 1564")
+ ("ngz"
+ "ED0E F1C8 E126 BA83 1B48 5FE9 DA00 B4F0 48E9 2F2D")
+ ("pelzflorian"
+ "CEF4 CB91 4856 BA38 0A20 A7E2 3008 88CB 39C6 3817")
+ ("pgarlick"
+ ;; primary: "B68B DF22 73F9 DA0E 63C1 8A32 515B F416 9242 D600"
+ "C699 ED09 E51B CE89 FD1D A078 AAC7 E891 896B 568A")
+ ("phant0mas"
+ "3A86 380E 58A8 B942 8D39 60E1 327C 1EF3 8DF5 4C32")
+ ("reepca"
+ "74D6 A930 F44B 9B84 9EA5 5606 C166 AA49 5F7F 189C")
+ ("rekado"
+ "BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC")
+ ("rhelling"
+ "0154 E1B9 1CC9 D9EF 7764 8DE7 F3A7 27DB 44FC CA36")
+ ("roelj (old)"
+ "17CB 2812 EB63 3DFF 2C7F 0452 C3EC 1DCA 8430 72E1")
+ ("roelj"
+ ;; From commit cc51c03ff867d4633505354819c6d88af88bf919 (March 2020).
+ ;; See <https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00070.html>.
+ "F556 FD94 FB8F 8B87 79E3 6832 CBD0 CD51 38C1 9AFC")
+ ("roptat (old)"
+ "B5FA E628 5B41 3728 B2A0 FAED 4311 1F45 2008 6A0C")
+ ("roptat"
+ ;; From commit 2cbede5935eb6a40173bbdf30a9ad22bf7574c22 (Jan. 2020). See
+ ;; <https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00499.html>.
+ "1EFB 0909 1F17 D28C CBF9 B13A 53D4 57B2 D636 EE82")
+ ("samplet"
+ ;; primary: "D6B0 C593 DA8C 5EDC A44C 7A58 C336 91F7 1188 B004"
+ "A02C 2D82 0EF4 B25B A6B5 1D90 2AC6 A5EC 1C35 7C59")
+ ("sleep_walker"
+ "77DD AD2D 97F5 31BB C0F3 C7FD DFB5 EB09 AA62 5423")
+ ("snape"
+ "F494 72F4 7A59 00D5 C235 F212 89F9 6D48 08F3 59C7")
+ ("steap"
+ "4E26 CCE9 578E 0828 9855 BDD4 1C79 95D2 D5A3 8336")
+ ("taylanub"
+ "9ADE 9ECF 2B19 C180 9C99 5CEA A1F4 CFCC 5283 6BAC")
+
+ ;; https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00826.html
+ ("thomasd"
+ ;; primary: "1DD1 681F E285 E07F 11DC 0C59 2E15 A6BC D77D 54FD"
+ "3D2C DA58 819C 08C2 A649 D43D 5C3B 064C 724A 5726")
+ ("thomasd (old)"
+ "A5C5 92EA 606E 7106 A6A3 BC08 98B2 1575 91E1 2B08")
+
+ ("toothbrush"
+ "D712 1D73 A40A 7264 9E43 ED7D F284 6B1A 0D32 C442")
+ ("vagrantc"
+ "6580 7361 3BFC C5C7 E2E4 5D45 DC51 8FC8 7F97 16AA")
+ ("wigust"
+ ;; primary: "C955 CC5D C048 7FB1 7966 40A9 199A F6A3 67E9 4ABB"
+ "7238 7123 8EAC EB63 4548 5857 167F 8EA5 001A FA9C")
+ ("wingo"
+ "FF47 8FB2 64DE 32EC 2967 25A3 DDC0 F535 8812 F8F2")))
+
+(define (openpgp-fingerprint->bytevector str)
+ (base16-string->bytevector
+ (string-downcase (string-filter char-set:hex-digit str))))
+
(define %guix-channel-introduction
- ;; Introduction of the official 'guix channel. The chosen commit is the
- ;; first one that introduces '.guix-authorizations' on the 'core-updates'
- ;; branch that was eventually merged in 'master'. Any branch starting
- ;; before that commit cannot be merged or it will be rejected by 'guix pull'
- ;; & co.
+ ;; Introduction of the official 'guix channel.
(make-channel-introduction
- "87a40d7203a813921b3ef0805c2b46c0026d6c31"
- (base16-string->bytevector
- (string-downcase
- (string-filter char-set:hex-digit ;mbakke
- "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")))
+ "6298c3ffd9654d3231a6f25390b056483e8f407c" ;v1.0.0
+ (openpgp-fingerprint->bytevector
+ "3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5") ;civodul
+
+ ;; The "prehistorical authorizations" lists authorized committers between
+ ;; v1.0.0 and the commit where '.guix-authorizations' was introduced.
+ (match %guix-historical-committers
+ (((_ fingerprints) ...)
+ (map openpgp-fingerprint->bytevector fingerprints)))
#f)) ;TODO: Add an intro signature so it can be exported.
(define %default-channel-url
@@ -331,6 +516,10 @@ fails."
(string-append keyring-reference-prefix
keyring-reference)))
+ (define prehistorical-authorizations
+ (channel-introduction-prehistorical-authorizations
+ (channel-introduction channel)))
+
(define authenticated-commits
;; Previously-authenticated commits that don't need to be checked again.
(filter-map (lambda (id)
@@ -381,6 +570,8 @@ commits ~a to ~a (~h new commits)...~%")
(lambda (report)
(authenticate-commits repository commits
#:keyring keyring
+ #:default-authorizations
+ prehistorical-authorizations
#:report-progress report)))
(unless (null? commits)
diff --git a/tests/channels.scm b/tests/channels.scm
index 5f13a48ec1..8c64d7a7c7 100644
--- a/tests/channels.scm
+++ b/tests/channels.scm
@@ -430,6 +430,7 @@
(openpgp-public-key-fingerprint
(read-openpgp-packet
%ed25519bis-public-key-file)) ;different key
+ '()
#f)) ;no signature
(channel (channel (name 'example)
(url (string-append "file://" directory))
@@ -486,6 +487,7 @@
(openpgp-public-key-fingerprint
(read-openpgp-packet
%ed25519-public-key-file))
+ '()
#f)) ;no signature
(channel (channel (name 'example)
(url (string-append "file://" directory))
--
2.26.2
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Mon, 08 Jun 2020 22:05:02 GMT) (full text, mbox, link).
Message #258 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Gah, I messed up. Please followup to 41767@debbugs.gnu.org! Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 09 Jun 2020 07:16:01 GMT) (full text, mbox, link).
Message #261 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Ludovic Courtès <ludo@gnu.org> skribis: > This patch series does it! It integrates checkout authentication > with (guix channels). Now, ‘guix pull’, ‘guix time-machine’ etc. > automatically authenticate the commits they fetch and raise an > error if they find an unsigned commit or a commit signed by an > unauthorized party¹. [...] > ¹ https://issues.guix.gnu.org/issue/22883#64 Something we didn’t discuss is that this model forbids a merge-request kind of workflow, or at least the person who merges must sign the commits, rewriting the merged branch. I think it’s a reasonable tradeoff in this space, but it’s worth keeping in mind. Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Sat, 13 Jun 2020 09:47:01 GMT) (full text, mbox, link).
Message #264 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hello Guix! Ludovic Courtès <ludo@gnu.org> skribis: > This patch series does it! It integrates checkout authentication > with (guix channels). Now, ‘guix pull’, ‘guix time-machine’ etc. > automatically authenticate the commits they fetch and raise an > error if they find an unsigned commit or a commit signed by an > unauthorized party¹. Last days to comment on this change! :-) https://issues.guix.gnu.org/41767 If there are no objections by then, I’ll push on Tuesday 16th. Ludo’.
Information forwarded
to bug-guix@gnu.org:
bug#22883; Package guix.
(Tue, 16 Jun 2020 14:24:01 GMT) (full text, mbox, link).
Message #267 received at 22883@debbugs.gnu.org (full text, mbox, reply):
Hi,
Ludovic Courtès <ludo@gnu.org> skribis:
> git-authenticate: Cache takes a key parameter.
> git-authenticate: 'authenticate-commits' takes a #:keyring parameter.
> tests: Move OpenPGP helpers to (guix tests gnupg).
> channels: 'latest-channel-instance' authenticates Git checkouts.
> channels: Make 'validate-pull' call right after clone/pull.
> .guix-channel: Add 'keyring-reference'.
> channels: Automatically add introduction for the official 'guix'
> channel.
> pull: Add '--disable-authentication'.
> DROP? channels: Add prehistorical authorizations to
> <channel-introduction>.
Pushed!
619972f7b5 maint: "make authenticate" behaves like 'guix pull' by default.
838ac881ec time-machine: Add '--disable-authentication'.
a9eeeaa6ae pull: Add '--disable-authentication'.
c3f6f564e9 channels: Automatically add introduction for the official 'guix' channel.
a941e8fe1f .guix-channel: Add 'keyring-reference'.
5bafc70d1e channels: Make 'validate-pull' call right after clone/pull.
43badf261f channels: 'latest-channel-instance' authenticates Git checkouts.
1e2b9bf2d4 tests: Move OpenPGP helpers to (guix tests gnupg).
41946b79f1 git-authenticate: 'authenticate-commits' takes a #:keyring parameter.
a450b4343b git-authenticate: Cache takes a key parameter.
I made the following changes:
1. The introductory of the ‘guix’ channel is now
9edb3f66fd807b096b48283debdcddccfea34bad (was
87a40d7203a813921b3ef0805c2b46c0026d6c31). This is because one of
the parents of 9edb3f66fd807b096b48283debdcddccfea34bad lacks
‘.guix-authorizations’. Consider it set in stone now!
2. I added ‘--disable-authentication’ for ‘guix time-machine’ in a
extra commit (it was easier than I thought because we don’t need to
disable inferior caching).
3. In an extra commit, I made “make authenticate” behave like ‘guix
pull’ by default—i.e., assume that commits whose parent lack the
‘.guix-authorizations’ file are unauthorized. It’s still possible
to run “make authenticate GUIX_USE_HISTORICAL_AUTHORIZATIONS=yes”
to assume “historical authorizations” for those commits.
Future work includes making that mechanism available to third-party
channels, which in turn means providing a public interface for “channel
introductions” and probably a ‘guix channel’ CLI, as discussed earlier.
Let me know if you notice anything wrong!
Ludo’.
Reply sent
to Ludovic Courtès <ludo@gnu.org>:
You have taken responsibility.
(Tue, 16 Jun 2020 14:36:02 GMT) (full text, mbox, link).
Notification sent
to Christopher Allan Webber <cwebber@dustycloud.org>:
bug acknowledged by developer.
(Tue, 16 Jun 2020 14:36:02 GMT) (full text, mbox, link).
Message #272 received at 22883-done@debbugs.gnu.org (full text, mbox, reply):
Hi! Ludovic Courtès <ludo@gnu.org> skribis: > Pushed! > > 619972f7b5 maint: "make authenticate" behaves like 'guix pull' by default. > 838ac881ec time-machine: Add '--disable-authentication'. > a9eeeaa6ae pull: Add '--disable-authentication'. > c3f6f564e9 channels: Automatically add introduction for the official 'guix' channel. > a941e8fe1f .guix-channel: Add 'keyring-reference'. > 5bafc70d1e channels: Make 'validate-pull' call right after clone/pull. > 43badf261f channels: 'latest-channel-instance' authenticates Git checkouts. > 1e2b9bf2d4 tests: Move OpenPGP helpers to (guix tests gnupg). > 41946b79f1 git-authenticate: 'authenticate-commits' takes a #:keyring parameter. > a450b4343b git-authenticate: Cache takes a key parameter. Like I wrote, there’s still work to be done in this area, but at least we can now have the pleasure to close this 4-year old bug. \o/ https://issues.guix.gnu.org/22883 Ludo’.
bug archived.
Request was from Debbugs Internal Request <help-debbugs@gnu.org>
to internal_control@debbugs.gnu.org.
(Wed, 15 Jul 2020 11:24:07 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.