unofficial mirror of guix-devel@gnu.org 
 help / color / Atom feed
From: Justus Winter <teythoon@avior.uberspace.de>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Securing the software distribution chain
Date: Fri, 31 Jul 2020 11:20:43 +0200
Message-ID: <87lfj0ujkk.fsf@europa.jade-hamburg.de> (raw)
In-Reply-To: <87ime9w23i.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4694 bytes --]

Hello :)

Ludovic Courtès <ludo@gnu.org> writes:
> Justus Winter <teythoon@avior.uberspace.de> skribis:
>> So I think two things need to happen before this step can be improved:
>> The package metadata should include the URL of the signature and a set
>> of cryptographic identities eligible for signing the artifact.
>
> The idea of storing cryptographic metadata directly in <origin> has been
> discussed a few times:
>
>   https://lists.gnu.org/archive/html/help-guix/2016-08/msg00132.html
>   https://lists.gnu.org/archive/html/guix-devel/2015-10/msg00118.html
>   https://git.savannah.gnu.org/cgit/guix.git/tree/TODO?id=6b8875c838d637773813899b35a9b5ea4acfd146#n29
>
> To me, the biggest shortcoming of this approach is if this metadata is
> primarily “ornamental”: if in practice, ‘guix build -S’ doesn’t use it
> (and it has no reason to use it), then that metadata is likely to become
> stale without anyone noticing.

On the other hand, most packaging metadata is ornamental.  There is no
way to tell if synopsis or description is up to date or correct.  With
signing metadata there is a way to detect this, so I don't see how
tracking signing metadata is worse than tracking the description.

> Of course we could have additional tools to make use of that info, say
> ‘guix build -S --authenticate’ or something.  But that would still be
> optional.

Don't make it optional!  Empower and encourage us downstream users to
verify upstream signatures and verify that the packager is honest, like
you empower us to build software and verify that the substitution
builder is honest.

You know, I recently packaged dkgpg.  That software is distributed as a
signed tarball (or rather, there is a detached signature for the
tarball).  Did I check that signature before storing the hashsum in the
packages metadata?  You know I did.  Currently, you just need to trust
me on that.  Or did I?

>> Thinking a bit more about having a hashsum as part of the packaging
>> definition, it seems to me that this is a bit of a modelling error.
>> Because there is no standardized way of authenticating a source
>> distribution, Guix defers this step to the packager.  And if there is no
>> way to authenticate an artifact (because upstream doesn't provide
>> signatures), we at least get TOFU, i.e. the assurance that any user
>> gets the same artifact as the packager.
>>
>> This doesn't seem terribly problematic, but it doesn't support parts of
>> the artifact changing, because in this model, this cannot be
>> distinguished from an attack.  Is there a way an artifact may change in
>> a valid way that Guix (and other distributions) may want to support?
>
> What do you mean?  If, for example, a tarball is modified in-place
> upstream, it’s an error from Guix’ viewpoint.

I mean that the tarball inside the OpenPGP message stays the same, but
we attach more signatures to the OpenPGP message over time.

>> We believe there is.  We propose to solve the problem of locating the
>> signatures by bundling them with the source distribution.  Instead of
>> using a detached PGP signature, we want to distribute the source as a
>> signed PGP message.
>>
>> Now, if you compute a hashsum over such an artifact, you are in effect
>> notarizing the signatures in the message and the message payload.  If
>> the developers add a signature to the message, the hashsum changes and
>> your notarization breaks.
>>
>> The preferred way to support this is to not verify that the hashsum over
>> the artifact matches, but to verify the PGP signatures over the payload
>> using the set of eligible signing keys in the package metadata.
>
> In practice, we don’t get to choose the authentication method.  You’re
> proposing a different authentication method here, but we’re just
> downstream: you’ll have to convince upstreams first.  :-)

Well, I'm a upstream, and this is your heads up that you are not
prepared to deal with our source distribution scheme of choice.  And,
we're hoping to convince other projects to use our scheme as well.

We've been talking about this problem internally, and we have concluded
that it is useful to be able to pin the source tarball to an exact
version as you do now.  That is possible with our scheme by hashing only
the literal data of the signed OpenPGP message.  That requires some
OpenPGP parsing, but guix/openpgp.scm should support that.

> Content-addressing is nice, but not very useful if each tool (IPFS, SWH,
> Git, Guix) has its own way to address content…

I don't understand the relation to content-addressing, sorry.


Thanks :)
Justus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

      parent reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-23 11:07 Justus Winter
2020-07-27 12:53 ` Ludovic Courtès
2020-07-27 18:13   ` zimoun
2020-07-31  9:20   ` Justus Winter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lfj0ujkk.fsf@europa.jade-hamburg.de \
    --to=teythoon@avior.uberspace.de \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

unofficial mirror of guix-devel@gnu.org 

Archives are clonable:
	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git