unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Securing the software distribution chain
@ 2020-07-23 11:07 Justus Winter
  2020-07-27 12:53 ` Ludovic Courtès
  0 siblings, 1 reply; 6+ messages in thread
From: Justus Winter @ 2020-07-23 11:07 UTC (permalink / raw)
  To: guix-devel

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

Hello :)

doing some packaging lately I noticed a weak link in Guix'
authentication chain.  Artifacts downloaded by Guix are authenticated
using a hashsum included in the packaging definition, and 'guix
download' will compute this hashsum over artifacts, but the step of
authenticating the artifact is a manual one, mentioned in the
'Submitting Patches' checklist:

> Before submitting a patch that adds or modifies a package definition,
> please run through this check list:
>
> 1. If the authors of the packaged software provide a cryptographic
>    signature for the release tarball, make an effort to verify the
>    authenticity of the archive. For a detached GPG signature file this
>    would be done with the gpg --verify command.

For me, this is a tooling problem.  'guix download' should authenticate
the downloaded artifact before it computes and prints the hashsum.
There are two problems to solve: It needs to locate the signature, and
it has to know the set of cryptographic identities eligible to create
the signature.

For some transports, like git, locating the signatures is not a problem,
but for http, there is just no standard on where the detatched signature
is located, or even what data it is computed over (for example,
kernel.org signs the uncompressed tarball).

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.


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?

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.


Thoughts?
Justus

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-08-25 10:01 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-23 11:07 Securing the software distribution chain Justus Winter
2020-07-27 12:53 ` Ludovic Courtès
2020-07-27 18:13   ` zimoun
2020-07-31  9:20   ` Justus Winter
2020-08-24 14:36     ` Ludovic Courtès
2020-08-25 10:01       ` Efraim Flashner

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).