Source downloader accepts X.509 certificate for incorrect domain

Done

Details

7 participants

Leo Famulari
Ludovic Courtès
Marius Bakke
Mark H Weaver
Mike Gerwitz
ng0
Ricardo Wurmus

Owner: unassigned

Submitted by: Leo Famulari

Severity: normal

Leo Famulari wrote on 21 Jun 2017 08:17

Recipients:(address . bug-guix@gnu.org)

Message-ID:20170621061752.GA32412@jasmine.lan

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

------

Ludovic Courtès wrote on 21 Jun 2017 12:50

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 27437@debbugs.gnu.org)

Message-ID:87lgolipi0.fsf@gnu.org

Hi,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (23 lines)> 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:

Toggle snippet (11 lines)

$ 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

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’.

Leo Famulari wrote on 22 Jun 2017 06:09

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 27437@debbugs.gnu.org)

Message-ID:20170622040901.GA8700@jasmine.lan

On Wed, Jun 21, 2017 at 12:50:15PM +0200, Ludovic Courtès wrote:

Toggle quote (4 lines)

> 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.

[...]

Toggle quote (6 lines)

> 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!

Ludovic Courtès wrote on 22 Jun 2017 09:57

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 27437@debbugs.gnu.org)

Message-ID:87zid0qwt8.fsf@gnu.org

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (21 lines)> 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’.

Mark H Weaver wrote on 22 Jun 2017 17:33

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87injohwac.fsf@netris.org

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

Toggle quote (15 lines)> 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

Leo Famulari wrote on 22 Jun 2017 18:11

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:20170622161108.GA15580@jasmine.lan

On Thu, Jun 22, 2017 at 11:33:31AM -0400, Mark H Weaver wrote:

Toggle quote (15 lines)> 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 :/

Toggle quote (7 lines)

> 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.

Leo Famulari wrote on 22 Jun 2017 18:16

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 27437@debbugs.gnu.org)

Message-ID:20170622161609.GB15580@jasmine.lan

On Thu, Jun 22, 2017 at 09:57:23AM +0200, Ludovic Courtès wrote:

Toggle quote (7 lines)

> > 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.

Toggle quote (5 lines)

> 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.

Ludovic Courtès wrote on 22 Jun 2017 21:12

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:87wp83rg4k.fsf@gnu.org

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (19 lines)> 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:

Toggle snippet (22 lines)$ 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.

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’.

ng0 wrote on 22 Jun 2017 23:30

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:20170622213036.kvcwug7l3xf5yyhu@abyayala

Leo Famulari transcribed 2.4K bytes:

Toggle quote (30 lines)> 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

Ricardo Wurmus wrote on 22 Jun 2017 23:45

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:87o9tf1ytl.fsf@elephly.net

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

Toggle quote (4 lines)

> 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

Marius Bakke wrote on 23 Jun 2017 00:32

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

Recipients:(address . 27437@debbugs.gnu.org)

Message-ID:87shirodr0.fsf@fastmail.com

Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (9 lines)

> 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

Mike Gerwitz wrote on 23 Jun 2017 02:45

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

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87y3sj7cqx.fsf@gnu.org

On Thu, Jun 22, 2017 at 21:12:27 +0200, Ludovic Courtès wrote:

Toggle quote (5 lines)

> 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

Leo Famulari wrote on 23 Jun 2017 05:24

Recipients:(name . Ricardo Wurmus)(address . rekado@elephly.net)

Message-ID:20170623032401.GA13366@jasmine.lan

On Thu, Jun 22, 2017 at 11:45:26PM +0200, Ricardo Wurmus wrote:

Toggle quote (10 lines)> 
> 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.

Ricardo Wurmus wrote on 23 Jun 2017 09:29

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:87fuer9n6d.fsf@elephly.net

Leo Famulari <leo@famulari.name> writes:

Toggle quote (18 lines)> 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?

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(+)

Toggle diff (19 lines)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

Ricardo

GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC

https://elephly.net

Ludovic Courtès wrote on 23 Jun 2017 11:31

Recipients:(name . Mike Gerwitz)(address . mtg@gnu.org)

Message-ID:87podvaw3n.fsf@gnu.org

Mike Gerwitz <mtg@gnu.org> skribis:

Toggle quote (8 lines)

> 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’.

Ludovic Courtès wrote on 27 Jul 2017 14:29

Recipients:(name . Ricardo Wurmus)(address . rekado@elephly.net)

Message-ID:87k22u3vx2.fsf@gnu.org

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (24 lines)>>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’.

Ricardo Wurmus wrote on 27 Jul 2017 21:34

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87r2x165dm.fsf@elephly.net

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

Toggle quote (30 lines)> 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

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 27437@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 27437

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date