GNU bug report logs -
#27437
Source downloader accepts X.509 certificate for incorrect domain
Previous Next
Reported by: Leo Famulari <leo <at> famulari.name>
Date: Wed, 21 Jun 2017 06:19:01 UTC
Severity: normal
Done: Ricardo Wurmus <rekado <at> elephly.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 27437 in the body.
You can then email your comments to 27437 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Wed, 21 Jun 2017 06:19:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Leo Famulari <leo <at> famulari.name>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Wed, 21 Jun 2017 06:19:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
------
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Wed, 21 Jun 2017 10:51:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 27437 <at> debbugs.gnu.org (full text, mbox):
Hi,
Leo Famulari <leo <at> 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’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Thu, 22 Jun 2017 04:10:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 27437 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Jun 21, 2017 at 12:50:15PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo <at> 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!
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Thu, 22 Jun 2017 07:58:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 27437 <at> debbugs.gnu.org (full text, mbox):
Leo Famulari <leo <at> famulari.name> skribis:
> On Wed, Jun 21, 2017 at 12:50:15PM +0200, Ludovic Courtès wrote:
>> Leo Famulari <leo <at> 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’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Thu, 22 Jun 2017 15:35:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 27437 <at> debbugs.gnu.org (full text, mbox):
ludo <at> 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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Thu, 22 Jun 2017 16:12:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 27437 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Jun 22, 2017 at 11:33:31AM -0400, Mark H Weaver wrote:
> ludo <at> 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.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Thu, 22 Jun 2017 16:17:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 27437 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Thu, 22 Jun 2017 19:13:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 27437 <at> debbugs.gnu.org (full text, mbox):
Leo Famulari <leo <at> famulari.name> skribis:
> On Thu, Jun 22, 2017 at 11:33:31AM -0400, Mark H Weaver wrote:
>> ludo <at> 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’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Thu, 22 Jun 2017 21:32:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 27437 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Leo Famulari transcribed 2.4K bytes:
> On Thu, Jun 22, 2017 at 11:33:31AM -0400, Mark H Weaver wrote:
> > ludo <at> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Thu, 22 Jun 2017 21:46:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 27437 <at> debbugs.gnu.org (full text, mbox):
Mark H Weaver <mhw <at> 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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Thu, 22 Jun 2017 22:33:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 27437 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ricardo Wurmus <rekado <at> elephly.net> writes:
> Mark H Weaver <mhw <at> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Fri, 23 Jun 2017 00:47:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 27437 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Fri, 23 Jun 2017 03:25:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 27437 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Jun 22, 2017 at 11:45:26PM +0200, Ricardo Wurmus wrote:
>
> Mark H Weaver <mhw <at> 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.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Fri, 23 Jun 2017 07:31:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 27437 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Leo Famulari <leo <at> famulari.name> writes:
> On Thu, Jun 22, 2017 at 11:45:26PM +0200, Ricardo Wurmus wrote:
>>
>> Mark H Weaver <mhw <at> 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?
[0001-doc-Encourage-signature-verification.patch (text/x-patch, inline)]
From 44b8f1c04713d11601d964ecfbe2fc248a15e7c0 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus <rekado <at> 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
[Message part 3 (text/plain, inline)]
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Fri, 23 Jun 2017 09:32:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 27437 <at> debbugs.gnu.org (full text, mbox):
Mike Gerwitz <mtg <at> 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’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#27437
; Package
guix
.
(Thu, 27 Jul 2017 12:30:03 GMT)
Full text and
rfc822 format available.
Message #50 received at 27437 <at> debbugs.gnu.org (full text, mbox):
Ricardo Wurmus <rekado <at> elephly.net> skribis:
>>From 44b8f1c04713d11601d964ecfbe2fc248a15e7c0 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus <rekado <at> 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’.
Reply sent
to
Ricardo Wurmus <rekado <at> elephly.net>
:
You have taken responsibility.
(Thu, 27 Jul 2017 19:35:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Leo Famulari <leo <at> famulari.name>
:
bug acknowledged by developer.
(Thu, 27 Jul 2017 19:35:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 27437-done <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> Ricardo Wurmus <rekado <at> elephly.net> skribis:
>
>>>From 44b8f1c04713d11601d964ecfbe2fc248a15e7c0 Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus <rekado <at> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 25 Aug 2017 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 239 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.