bug#27437: Source downloader accepts X.509 certificate for incorrect domain

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Leo Famulari]

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

While working on some package updates, I found that the source code
downloader will accept an X.509 certificate for an incorrect site.

Here is what happens:

------
$ ./pre-inst-env guix build -S opus-tools --check
@ build-started /gnu/store/nn93hkik8kvrigcf2pvmym01zg7jqm4v-opus-tools-0.1.10.tar.gz.drv - x86_64-linux /var/log/guix/drvs/nn//93hkik8kvrigcf2pvmym01zg7jqm4v-opus-tools-0.1.10.tar.gz.drv.bz2
 
Starting download of /gnu/store/0js62s7pz9gfcdsd1n764w91mhhwkws4-opus-tools-0.1.10.tar.gz
From https://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz...
 ….1.10.tar.gz  305KiB              822KiB/s 00:00 [####################] 100.0%
warning: rewriting hashes in `/gnu/store/vdpyfqzp0kkjpxr79fq3an7j4s4vkz0h-opus-tools-0.1.10.tar.gz'; cross fingers
/gnu/store/vdpyfqzp0kkjpxr79fq3an7j4s4vkz0h-opus-tools-0.1.10.tar.gz
------

Here is an example of what I think should happen in this case:

------
$ curl https://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz
curl: (51) SSL: certificate subject name (osuosl.org) does not match target host name 'downloads.xiph.org'
------

And this is what Firefox says:

------
downloads.xiph.org uses an invalid security certificate.

The certificate is only valid for the following names:
  osuosl.org, *.osuosl.org  

Error code: SSL_ERROR_BAD_CERT_DOMAIN
------


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

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Ludovic Courtès]

Hi,

Leo Famulari <leo@famulari.name> skribis:

> While working on some package updates, I found that the source code
> downloader will accept an X.509 certificate for an incorrect site.
>
> Here is what happens:
>
> ------
> $ ./pre-inst-env guix build -S opus-tools --check
> @ build-started /gnu/store/nn93hkik8kvrigcf2pvmym01zg7jqm4v-opus-tools-0.1.10.tar.gz.drv - x86_64-linux /var/log/guix/drvs/nn//93hkik8kvrigcf2pvmym01zg7jqm4v-opus-tools-0.1.10.tar.gz.drv.bz2
>  
> Starting download of /gnu/store/0js62s7pz9gfcdsd1n764w91mhhwkws4-opus-tools-0.1.10.tar.gz
> From https://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz...
>  ….1.10.tar.gz  305KiB              822KiB/s 00:00 [####################] 100.0%
> warning: rewriting hashes in `/gnu/store/vdpyfqzp0kkjpxr79fq3an7j4s4vkz0h-opus-tools-0.1.10.tar.gz'; cross fingers
> /gnu/store/vdpyfqzp0kkjpxr79fq3an7j4s4vkz0h-opus-tools-0.1.10.tar.gz
> ------
>
> Here is an example of what I think should happen in this case:
>
> ------
> $ curl https://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz
> curl: (51) SSL: certificate subject name (osuosl.org) does not match target host name 'downloads.xiph.org'
> ------

Also:

--8<---------------cut here---------------start------------->8---
$ guix download https://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz

Starting download of /tmp/guix-file.vjPVRk
From https://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz...
ERROR: X.509 server certificate for 'downloads.xiph.org' does not match: C=US,postalCode=97331,ST=OR,L=Corvallis,street=Oregon State University,street=Kerr Admin Building,O=Oregon State University,OU=OSU OSL,CN=osuosl.org

failed to download "/tmp/guix-file.vjPVRk" from "https://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz"
guix download: error:
https://downloads.xiph.org/releases/opus/opus-tools-0.1.10.tar.gz: download failed
--8<---------------cut here---------------end--------------->8---

The behavior of the source download is on purpose as noted in (guix
download):

                       ;; No need to validate certificates since we know the
                       ;; hash of the expected result.
                       #:verify-certificate? #f)))))

IOW, since we’re checking the integrity of the tarball anyway, and we
assume developers checked its authenticity when writing the recipe, then
who cares whether downloads.xiph.org has a valid certificate?

Conversely, ‘guix download’ always checks certificates by default.

Does it make sense?

Ludo’.

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Leo Famulari]

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

On Wed, Jun 21, 2017 at 12:50:15PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > While working on some package updates, I found that the source code
> > downloader will accept an X.509 certificate for an incorrect site.

[...]

> IOW, since we’re checking the integrity of the tarball anyway, and we
> assume developers checked its authenticity when writing the recipe, then
> who cares whether downloads.xiph.org has a valid certificate?
> 
> Does it make sense?

Yeah, I think it makes sense if checking the certificates would add too
much complexity for what I think is a minor benefit: protecting against
exploitation of bugs by MITM (but not xiph.org) in whatever code runs
after the connection is initiated and before the hash is calculated.

Perhaps a MITM could send a huge file and fill up the disk or something
like that.

Closing the bug, but more thoughts are welcome!

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

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Jun 21, 2017 at 12:50:15PM +0200, Ludovic Courtès wrote:
>> Leo Famulari <leo@famulari.name> skribis:
>> > While working on some package updates, I found that the source code
>> > downloader will accept an X.509 certificate for an incorrect site.
>
> [...]
>
>> IOW, since we’re checking the integrity of the tarball anyway, and we
>> assume developers checked its authenticity when writing the recipe, then
>> who cares whether downloads.xiph.org has a valid certificate?
>> 
>> Does it make sense?
>
> Yeah, I think it makes sense if checking the certificates would add too
> much complexity for what I think is a minor benefit: protecting against
> exploitation of bugs by MITM (but not xiph.org) in whatever code runs
> after the connection is initiated and before the hash is calculated.
>
> Perhaps a MITM could send a huge file and fill up the disk or something
> like that.

I’m generally in favor of relying on X.509 certificates as little as
possible, and in this case, while I agree that it could protect us
against the scenario you describe, I think it’s a bit of a stretch.

However, we’d very likely have bug reports of people for which downloads
fail because of various issues in the X.509 infrastructure and/or in how
the they set up their system (‘nss-certs’ uninstalled or too old,
SSL_CERT_DIR unset, etc.)

Thoughts?

Thanks,
Ludo’.

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Leo Famulari]

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

On Thu, Jun 22, 2017 at 09:57:23AM +0200, Ludovic Courtès wrote:
> > Perhaps a MITM could send a huge file and fill up the disk or something
> > like that.
> 
> I’m generally in favor of relying on X.509 certificates as little as
> possible, and in this case, while I agree that it could protect us
> against the scenario you describe, I think it’s a bit of a stretch.

Agreed, the X.509 PKI is really brittle, and so I think our current
choice is reaosnable.

It's different for `guix pull` because we don't use the full PKI, we
control most of the code involved, and we have a good relationship with
the Savannah admins. Of course, we should eventually improve `guix pull`
to verify code signatures instead.

> However, we’d very likely have bug reports of people for which downloads
> fail because of various issues in the X.509 infrastructure and/or in how
> the they set up their system (‘nss-certs’ uninstalled or too old,
> SSL_CERT_DIR unset, etc.)

Indeed, that would be super-annoying.

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

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> The behavior of the source download is on purpose as noted in (guix
> download):
>
>                        ;; No need to validate certificates since we know the
>                        ;; hash of the expected result.
>                        #:verify-certificate? #f)))))
>
> IOW, since we’re checking the integrity of the tarball anyway, and we
> assume developers checked its authenticity when writing the recipe, then
> who cares whether downloads.xiph.org has a valid certificate?
>
> Conversely, ‘guix download’ always checks certificates by default.
>
> Does it make sense?

Yes, and I agree with this behavior.  However, it should be noted that
this will reduce the security of a bad practice that I suspect is
sometimes used by people when updating packages, namely to update the
version number, try building it, and then copy the hash from the error
message to the package.

FWIW, I always check digital signatures when they're available, and I
hope that others will as well, but in practice we are putting our faith
in a large number of contributors, some of whom might not be so careful.

Also, sadly, many packages are distributed without digital signatures at
all.  One glaring example is NSS.

       Mark

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Leo Famulari]

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

On Thu, Jun 22, 2017 at 11:33:31AM -0400, Mark H Weaver wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
> > IOW, since we’re checking the integrity of the tarball anyway, and we
> > assume developers checked its authenticity when writing the recipe, then
> > who cares whether downloads.xiph.org has a valid certificate?
> >
> > Conversely, ‘guix download’ always checks certificates by default.
> >
> > Does it make sense?
> 
> Yes, and I agree with this behavior.  However, it should be noted that
> this will reduce the security of a bad practice that I suspect is
> sometimes used by people when updating packages, namely to update the
> version number, try building it, and then copy the hash from the error
> message to the package.

Yeah, that's a bad habit and I warn people against it whenever it comes
up :/

> FWIW, I always check digital signatures when they're available, and I
> hope that others will as well, but in practice we are putting our faith
> in a large number of contributors, some of whom might not be so careful.
> 
> Also, sadly, many packages are distributed without digital signatures at
> all.  One glaring example is NSS.

Do we have any contacts at Mozilla we can talk to about this? I imagine
it's a long shot, with many bureaucratic hurdles, but it's worth asking
for.

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

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Jun 22, 2017 at 11:33:31AM -0400, Mark H Weaver wrote:
>> ludo@gnu.org (Ludovic Courtès) writes:
>> > IOW, since we’re checking the integrity of the tarball anyway, and we
>> > assume developers checked its authenticity when writing the recipe, then
>> > who cares whether downloads.xiph.org has a valid certificate?
>> >
>> > Conversely, ‘guix download’ always checks certificates by default.
>> >
>> > Does it make sense?
>> 
>> Yes, and I agree with this behavior.  However, it should be noted that
>> this will reduce the security of a bad practice that I suspect is
>> sometimes used by people when updating packages, namely to update the
>> version number, try building it, and then copy the hash from the error
>> message to the package.
>
> Yeah, that's a bad habit and I warn people against it whenever it comes
> up :/

Agreed.

That said, if we look at our updaters:

--8<---------------cut here---------------start------------->8---
$ guix refresh --list-updaters 
Available updaters:

  - cpan: Updater for CPAN packages (9.2% coverage)
  - cran: Updater for CRAN packages (4.0% coverage)
  - bioconductor: Updater for Bioconductor packages (1.2% coverage)
  - crates: Updater for crates.io packages (.0% coverage)
  - elpa: Updater for ELPA packages (.3% coverage)
  - gem: Updater for RubyGem packages (2.5% coverage)
  - github: Updater for GitHub packages (10.5% coverage)
  - hackage: Updater for Hackage packages (5.2% coverage)
  - pypi: Updater for PyPI packages (17.6% coverage)
  - stackage: Updater for Stackage LTS packages (5.2% coverage)
  - kernel.org: Updater for packages hosted on kernel.org (.5% coverage)
  - gnome: Updater for GNOME packages (2.9% coverage)
  - xorg: Updater for X.org packages (3.2% coverage)
  - gnu: Updater for GNU packages (5.6% coverage)
  - kde: Updater for KDE packages (1.3% coverage)

69.0% of the packages are covered by these updaters.
--8<---------------cut here---------------end--------------->8---

I think only GNU and kernel.org provide signatures, which represents 6%
of our packages.  Of the 30% that do not have an updater, surely some
have digital signatures, but we’re probably still below 10%.  The
situation is bad in general…

Ludo’.

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Mike Gerwitz]

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

On Thu, Jun 22, 2017 at 21:12:27 +0200, Ludovic Courtès wrote:
> I think only GNU and kernel.org provide signatures, which represents 6%
> of our packages.  Of the 30% that do not have an updater, surely some
> have digital signatures, but we’re probably still below 10%.  The
> situation is bad in general…

What about signed tags/commits?

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

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

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Ludovic Courtès]

Mike Gerwitz <mtg@gnu.org> skribis:

> On Thu, Jun 22, 2017 at 21:12:27 +0200, Ludovic Courtès wrote:
>> I think only GNU and kernel.org provide signatures, which represents 6%
>> of our packages.  Of the 30% that do not have an updater, surely some
>> have digital signatures, but we’re probably still below 10%.  The
>> situation is bad in general…
>
> What about signed tags/commits?

They’re becoming more widespread, especially now that GitHub’s UI can
make sense of them.  Nevertheless, I don’t think it changes the ratio
much if we look at the whole package set that we have.

Ludo’.

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[ng0]

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

Leo Famulari transcribed 2.4K bytes:
> On Thu, Jun 22, 2017 at 11:33:31AM -0400, Mark H Weaver wrote:
> > ludo@gnu.org (Ludovic Courtès) writes:
> > > IOW, since we’re checking the integrity of the tarball anyway, and we
> > > assume developers checked its authenticity when writing the recipe, then
> > > who cares whether downloads.xiph.org has a valid certificate?
> > >
> > > Conversely, ‘guix download’ always checks certificates by default.
> > >
> > > Does it make sense?
> > 
> > Yes, and I agree with this behavior.  However, it should be noted that
> > this will reduce the security of a bad practice that I suspect is
> > sometimes used by people when updating packages, namely to update the
> > version number, try building it, and then copy the hash from the error
> > message to the package.
> 
> Yeah, that's a bad habit and I warn people against it whenever it comes
> up :/
> 
> > FWIW, I always check digital signatures when they're available, and I
> > hope that others will as well, but in practice we are putting our faith
> > in a large number of contributors, some of whom might not be so careful.
> > 
> > Also, sadly, many packages are distributed without digital signatures at
> > all.  One glaring example is NSS.
> 
> Do we have any contacts at Mozilla we can talk to about this? I imagine
> it's a long shot, with many bureaucratic hurdles, but it's worth asking
> for.

One way is their bugtracker. Does anyone of us have an Account at their
bugzilla?

If it can't be discussed via bugzilla, there must be some mailinglist
for the nss development.
-- 
ng0
OpenPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://krosos.org/~/ng0/ https://www.infotropique.org

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

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Ricardo Wurmus]

Mark H Weaver <mhw@netris.org> writes:

> FWIW, I always check digital signatures when they're available, and I
> hope that others will as well, but in practice we are putting our faith
> in a large number of contributors, some of whom might not be so careful.

I do the same when signatures are available.  I couldn’t find this
recommendation in “contributing.texi” — should we add it there?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Marius Bakke]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> FWIW, I always check digital signatures when they're available, and I
>> hope that others will as well, but in practice we are putting our faith
>> in a large number of contributors, some of whom might not be so careful.
>
> I do the same when signatures are available.  I couldn’t find this
> recommendation in “contributing.texi” — should we add it there?

I think so. Many contributors won't have used GnuPG before downloading
Guix and may not remember how/why when it's time to package something.

There are a fair amount of PyPi packages that are signed, I've been
meaning to make the updater aware of it. See scipy, numpy and friends.
Wouldn't mind if someone beats me to it!

As far as NSS goes, releases are announced at their "dev-tech-crypto"
mailing list[0], but the announcements are not signed either (nor do
they contain hashes). The only authenticity they provide is the TLS
connection to ftp.mozilla.org[1].

Anyone up for drafting an email to the list?

[0] https://lists.mozilla.org/listinfo/dev-tech-crypto
[1] SHA256 fingerprint (valid until 2020):
3B:9F:F6:DC:11:F8:96:B1:62:60:3D:29:36:0B:E6:4E:69:F8:34:E9:B3:7A:05:7A:5B:84:CD:54:E5:8E:7C:8B

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

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Leo Famulari]

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

On Thu, Jun 22, 2017 at 11:45:26PM +0200, Ricardo Wurmus wrote:
> 
> Mark H Weaver <mhw@netris.org> writes:
> 
> > FWIW, I always check digital signatures when they're available, and I
> > hope that others will as well, but in practice we are putting our faith
> > in a large number of contributors, some of whom might not be so careful.
> 
> I do the same when signatures are available.  I couldn’t find this
> recommendation in “contributing.texi” — should we add it there?

To me, it seems that the manual section Packaging Guidelines is a better
fit.

But, we tend to recommend people read Contributing, but rarely do I see
Packaging Guidelines recommended. I suppose it's assumed they will find
it themselves.

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

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Ricardo Wurmus]

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


Leo Famulari <leo@famulari.name> writes:

> On Thu, Jun 22, 2017 at 11:45:26PM +0200, Ricardo Wurmus wrote:
>> 
>> Mark H Weaver <mhw@netris.org> writes:
>> 
>> > FWIW, I always check digital signatures when they're available, and I
>> > hope that others will as well, but in practice we are putting our faith
>> > in a large number of contributors, some of whom might not be so careful.
>> 
>> I do the same when signatures are available.  I couldn’t find this
>> recommendation in “contributing.texi” — should we add it there?
>
> To me, it seems that the manual section Packaging Guidelines is a better
> fit.
>
> But, we tend to recommend people read Contributing, but rarely do I see
> Packaging Guidelines recommended. I suppose it's assumed they will find
> it themselves.

“Packaging Guidelines” refers to “Contributing”.  I tried to add this to
“Packaging Guidelines” but couldn’t find an appropriate place, so here’s
a patch that adds an item to the checklist in “Contributing”.

WDYT?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-doc-Encourage-signature-verification.patch --]
[-- Type: text/x-patch, Size: 1172 bytes --]

From 44b8f1c04713d11601d964ecfbe2fc248a15e7c0 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus <rekado@elephly.net>
Date: Fri, 23 Jun 2017 09:24:58 +0200
Subject: [PATCH] doc: Encourage signature verification.

* doc/contributing.texi (Submitting Patches): Remind contributors to verify
cryptographic signatures.
---
 doc/contributing.texi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 925c584e4..0073f2451 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -334,6 +334,12 @@ updates for a given software package in a single place and have them
 affect the whole system---something that bundled copies prevent.
 
 @item
+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 @code{gpg --verify} command.
+
+@item
 Take a look at the profile reported by @command{guix size}
 (@pxref{Invoking guix size}).  This will allow you to notice references
 to other packages unwillingly retained.  It may also help determine
-- 
2.12.2


[-- Attachment #3: Type: text/plain, Size: 90 bytes --]


-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

>From 44b8f1c04713d11601d964ecfbe2fc248a15e7c0 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus <rekado@elephly.net>
> Date: Fri, 23 Jun 2017 09:24:58 +0200
> Subject: [PATCH] doc: Encourage signature verification.
>
> * doc/contributing.texi (Submitting Patches): Remind contributors to verify
> cryptographic signatures.
> ---
>  doc/contributing.texi | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/doc/contributing.texi b/doc/contributing.texi
> index 925c584e4..0073f2451 100644
> --- a/doc/contributing.texi
> +++ b/doc/contributing.texi
> @@ -334,6 +334,12 @@ updates for a given software package in a single place and have them
>  affect the whole system---something that bundled copies prevent.
>  
>  @item
> +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 @code{gpg --verify} command.

I would make it the very first item of the check list.

If that’s fine with you, please push and maybe close the bug!

Ludo’.

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

[Ricardo Wurmus]

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

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>>From 44b8f1c04713d11601d964ecfbe2fc248a15e7c0 Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus <rekado@elephly.net>
>> Date: Fri, 23 Jun 2017 09:24:58 +0200
>> Subject: [PATCH] doc: Encourage signature verification.
>>
>> * doc/contributing.texi (Submitting Patches): Remind contributors to verify
>> cryptographic signatures.
>> ---
>>  doc/contributing.texi | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/doc/contributing.texi b/doc/contributing.texi
>> index 925c584e4..0073f2451 100644
>> --- a/doc/contributing.texi
>> +++ b/doc/contributing.texi
>> @@ -334,6 +334,12 @@ updates for a given software package in a single place and have them
>>  affect the whole system---something that bundled copies prevent.
>>  
>>  @item
>> +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 @code{gpg --verify} command.
>
> I would make it the very first item of the check list.
>
> If that’s fine with you, please push and maybe close the bug!

Looks like I’ve already pushed this a while back.  I’ll move it up to
the top of the list.  (And I’m closing this bug.)

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net