Packaging packages with GPG signed source archives

Packaging packages with GPG signed source archives

[Arun Isaac]

I am trying to package a package that provides a GPG signed source
archive. Is there any way to get Guix to verify this signature, by say,
specifying it in the 'origin' object of the 'source' field of the
package? What is the standard way this is done in Guix?

Thanks,
Arun Isaac.

Re: Packaging packages with GPG signed source archives

[Alex Kost]

Arun Isaac (2016-08-31 08:37 +0300) wrote:

> I am trying to package a package that provides a GPG signed source
> archive. Is there any way to get Guix to verify this signature, by say,
> specifying it in the 'origin' object of the 'source' field of the
> package? What is the standard way this is done in Guix?

I think the procedure is: a packager verifies the source and that's it.
Since a package has a hash of the source, we can be sure that the source
wasn't changed since it was packaged, so if we find that a package has
a compromised source, we can blame the packager.

-- 
Alex

Re: Packaging packages with GPG signed source archives

[Arun Isaac]

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


> I think the procedure is: a packager verifies the source and that's it.
> Since a package has a hash of the source, we can be sure that the source
> wasn't changed since it was packaged, so if we find that a package has
> a compromised source, we can blame the packager.

Ah, that sounds good enough. Still, for the sake of completion, it would
be nice for Guix to have support for verifying GPG signed source
archives. I used to run Parabola GNU/Linux, and its 'makepkg' verified
GPG signatures before building.

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

Re: Packaging packages with GPG signed source archives

[ng0]

Arun Isaac <arunisaac@systemreboot.net> writes:

> [ Unknown signature status ]
>
>> I think the procedure is: a packager verifies the source and that's it.
>> Since a package has a hash of the source, we can be sure that the source
>> wasn't changed since it was packaged, so if we find that a package has
>> a compromised source, we can blame the packager.
>
> Ah, that sounds good enough. Still, for the sake of completion, it would
> be nice for Guix to have support for verifying GPG signed source
> archives. I used to run Parabola GNU/Linux, and its 'makepkg' verified
> GPG signatures before building.

There is some portion of the Guix code which gets verified this way
(checking/verifying the source of guix itself i think and the gnu
importer), if you think this should be implemented for every case where
a gpg key is available, we should discuss it here.
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Packaging packages with GPG signed source archives

[Leo Famulari]

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

On Wed, Aug 31, 2016 at 01:17:57PM +0530, Arun Isaac wrote:
Alex Kost wrote:
> > I think the procedure is: a packager verifies the source and that's it.
> > Since a package has a hash of the source, we can be sure that the source
> > wasn't changed since it was packaged, so if we find that a package has
> > a compromised source, we can blame the packager.
> 
> Ah, that sounds good enough. Still, for the sake of completion, it would
> be nice for Guix to have support for verifying GPG signed source
> archives. I used to run Parabola GNU/Linux, and its 'makepkg' verified
> GPG signatures before building.

There was a discussion about verifying signatures of GNU packages using
a GNU keyring, but it didn't end up happening. This would have enabled a
more trustworthy automatic update system for the GNU packages. It should
be in the guix-devel mailing list archive.

In my opinion, a limitation of verifying signatures automatically is
that the web of trust requires us (humans) to make sure the key
corresponds to the person or group that we intend to trust.

GnuPG will automatically download a missing key when verifying a
signature, but it's up to us to decide if the key is worth trusting.

As Alex said, Guix packagers verify signatures and then put tarball
hashes into package definitions. So, I bet that Guix users don't often
verify the signatures themselves; instead they choose to trust the
packagers, which is one reason we started signing all our Git commits.

Does Parabola have some sort of keyring that all the upstream keys go
into? Or did I misinterpret your suggestion? I'm not familiar with the
Parabola package management system.

By the way, we still have some work to do on a related topic:
https://bugs.gnu.org/22883

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

Re: Packaging packages with GPG signed source archives

[Arun Isaac]

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


> Does Parabola have some sort of keyring that all the upstream keys go
> into? Or did I misinterpret your suggestion? I'm not familiar with the
> Parabola package management system.

No, Parabola does not collect upstream keys into any centralized keyring.

When you are building a package from source, the Parabola build system
verifies the GPG signature of the source archive if the developer's key
is in your keyring. Else, it raises an error and asks you to get the
required key manually. There is also an option that tells the build
system to automatically fetch the key if it is not in your keyring.

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

Re: Packaging packages with GPG signed source archives

[Ludovic Courtès]

Hi,

Arun Isaac <arunisaac@systemreboot.net> skribis:

> When you are building a package from source, the Parabola build system
> verifies the GPG signature of the source archive if the developer's key
> is in your keyring. Else, it raises an error and asks you to get the
> required key manually. There is also an option that tells the build
> system to automatically fetch the key if it is not in your keyring.

‘guix import’ and ‘guix refresh’ do that (when possible), and otherwise
packagers are expected to authenticate tarballs by themselves, as much
as possible (usually, I guess we often use a TOFU-style model because
that’s often the best one can do.)

An improvement that was proposed earlier is to store in package recipes
the fingerprint of the OpenPGP key a package was checked against.  That
would force packagers to formally specify what they did, and would allow
us to have tools that double-check; IOW, it could be thought of as TOFU
at the scale of our community, instead of per-packager:

  https://lists.gnu.org/archive/html/guix-devel/2015-10/msg00118.html

Help in this area is very much welcome!  :-)

(That said, more and more software is distributed via Git rather than as
tarballs, and most repos are unsigned; even if they were, there are
basically no tools to meaningfully authenticate a Git checkout…)

Ludo’.

Re: Packaging packages with GPG signed source archives

[Troy Sankey]

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

Quoting Ludovic Courtès (2016-08-31 16:21:49)
> (That said, more and more software is distributed via Git rather than as
> tarballs, and most repos are unsigned; even if they were, there are
> basically no tools to meaningfully authenticate a Git checkout…)

In that case, not all hope is lost---I've seen many projects sign git tags.

Troy

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJXx0EZAAoJEIRGmXXw0dCUWCMP/RnYnq2yhsmWqg5Nfu4zbOFc
vgMBIiOOrQAJHR7Uxic1oiyXyK2LR6qkb4F1uwySsASunpaI7wQG5O2AlvZ2fERO
n1YXLgJUQGozwigW6GXf9RhK1ZsH/2jnWnBECN0X7nUWpTsHCc4VEm4kr4jv5yHb
Ce+oC/QZ7RLPdR8IMKo08q2OAx6tjUuQd2lAHCKY2XL0zmRy8mQW8vPW7Qmabs7N
qYl2Ozw2O0bhpmkPAU+/bJLAPQqCzHHlKdYWKlfUYWAfBWE9SrpCyEDjydGZNKFs
9KScOZqz3Ay24tAykqOUqpGhax2tu6R9RMUj1+G4JLAN2RmD/YA1B1rX6MyYOpjW
qQS6uviY4eaJIJEWVbgKVTD5KZwvnZnyWyu928aydULx5h3lUq8HMwUIkwBxKWzR
YB45qsD6D89Z8YxBVPKn+mZDzPkz4e5DCRogl6aR1zPFr+7NNm5/qzBvyJfRW/dS
34qv0Pc8wiXh9RpKAa+1uzOpRQGTXcs7oiiv3O3oqhu7LVv/GlLqHbdOW1/9wcTA
z8y1Zvggnoi/0DERHt2YJ9I8cgivxnPwxxkHFrO3HN4jHQZXvzwPEZ2n36Hi/iW9
9Ark/7J8gNoBC98vfxNTIDYkoU/CUxttjotX7HG61jVoaqVGLc+ml4D4rvrALTSb
VEDs5lVeEjHYHMkxvcmX
=obZu
-----END PGP SIGNATURE-----

Re: Packaging packages with GPG signed source archives

[Ludovic Courtès]

Troy Sankey <sankeytms@gmail.com> skribis:

> Quoting Ludovic Courtès (2016-08-31 16:21:49)
>> (That said, more and more software is distributed via Git rather than as
>> tarballs, and most repos are unsigned; even if they were, there are
>> basically no tools to meaningfully authenticate a Git checkout…)
>
> In that case, not all hope is lost---I've seen many projects sign git tags.

Indeed, but signing is the easy part.  :-)

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#73

Ludo’.

Re: Packaging packages with GPG signed source archives

[ng0]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Arun Isaac <arunisaac@systemreboot.net> skribis:
>
>> When you are building a package from source, the Parabola build system
>> verifies the GPG signature of the source archive if the developer's key
>> is in your keyring. Else, it raises an error and asks you to get the
>> required key manually. There is also an option that tells the build
>> system to automatically fetch the key if it is not in your keyring.
>
> ‘guix import’ and ‘guix refresh’ do that (when possible), and otherwise
> packagers are expected to authenticate tarballs by themselves, as much
> as possible (usually, I guess we often use a TOFU-style model because
> that’s often the best one can do.)
>
> An improvement that was proposed earlier is to store in package recipes
> the fingerprint of the OpenPGP key a package was checked against.  That
> would force packagers to formally specify what they did, and would allow
> us to have tools that double-check; IOW, it could be thought of as TOFU
> at the scale of our community, instead of per-packager:
>
>   https://lists.gnu.org/archive/html/guix-devel/2015-10/msg00118.html
>
> Help in this area is very much welcome!  :-)
>
> (That said, more and more software is distributed via Git rather than as
> tarballs, and most repos are unsigned; even if they were, there are
> basically no tools to meaningfully authenticate a Git checkout…)
>
> Ludo’.
>

On the subject of git repos, I do not understand enough of the
git-download.scm at the moment to add this myself, but why don't we have
git-fsck in it as default?

-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Packaging packages with GPG signed source archives

[Ludovic Courtès]

Hi,

ng0 <ng0@we.make.ritual.n0.is> skribis:

> On the subject of git repos, I do not understand enough of the
> git-download.scm at the moment to add this myself, but why don't we have
> git-fsck in it as default?

Dunno; what would it add?

Ludo’.

Re: Packaging packages with GPG signed source archives

[ng0]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> ng0 <ng0@we.make.ritual.n0.is> skribis:
>
>> On the subject of git repos, I do not understand enough of the
>> git-download.scm at the moment to add this myself, but why don't we have
>> git-fsck in it as default?
>
> Dunno; what would it add?
>
> Ludo’.

I don't understand enough of it, I only know someone else added it to
some project I contribute to.
"...verifies the connectivity and validity of the objects in the
database.

git-fsck tests SHA-1 and general object sanity, and it does full
tracking of the resulting reachability and everything else. It prints
out any corruption it finds (missing or bad objects), and if you use the
--unreachable flag it will also print out objects that exist but that
aren’t reachable from any of the specified head nodes (or the default
set, as mentioned above).

Any corrupt objects you will have to find in backups or other archives
(i.e., you can just remove them and do an rsync with some other site in
the hopes that somebody else has the object you have corrupted)."
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Packaging packages with GPG signed source archives

[Ludovic Courtès]

ng0 <ng0@we.make.ritual.n0.is> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi,
>>
>> ng0 <ng0@we.make.ritual.n0.is> skribis:
>>
>>> On the subject of git repos, I do not understand enough of the
>>> git-download.scm at the moment to add this myself, but why don't we have
>>> git-fsck in it as default?
>>
>> Dunno; what would it add?
>>
>> Ludo’.
>
> I don't understand enough of it, I only know someone else added it to
> some project I contribute to.

Guix ‘origin’ forms store the expected SHA256 of the checkout.  So
everytime we do a Git checkout, guix-daemon explicitly makes sure the
the checkout contents match the given SHA256.  IOW, we already have
integrity checks built in Guix.  For this reason, I think ‘git fsck’
wouldn’t provide any additional guarantee.

Hope this makes sense!

Ludo’.

Re: Packaging packages with GPG signed source archives

[ng0]

Ludovic Courtès <ludo@gnu.org> writes:

> ng0 <ng0@we.make.ritual.n0.is> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hi,
>>>
>>> ng0 <ng0@we.make.ritual.n0.is> skribis:
>>>
>>>> On the subject of git repos, I do not understand enough of the
>>>> git-download.scm at the moment to add this myself, but why don't we have
>>>> git-fsck in it as default?
>>>
>>> Dunno; what would it add?
>>>
>>> Ludo’.
>>
>> I don't understand enough of it, I only know someone else added it to
>> some project I contribute to.
>
> Guix ‘origin’ forms store the expected SHA256 of the checkout.  So
> everytime we do a Git checkout, guix-daemon explicitly makes sure the
> the checkout contents match the given SHA256.  IOW, we already have
> integrity checks built in Guix.  For this reason, I think ‘git fsck’
> wouldn’t provide any additional guarantee.
>
> Hope this makes sense!
>
> Ludo’.

I agree

…and wonder if I run into equal problems once I have done the guix
publish/pull/package via gnunet-fs as Nix is discussing for the
distributed system they are discussing to move to, where their problem
is that they need to convert all the hashes for when they'll move all
the sources into that network. I'll see when I get there.
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org