* bug#27437: Source downloader accepts X.509 certificate for incorrect domain @ 2017-06-21 6:17 Leo Famulari 2017-06-21 10:50 ` Ludovic Courtès 0 siblings, 1 reply; 17+ messages in thread From: Leo Famulari @ 2017-06-21 6:17 UTC (permalink / raw) To: 27437 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-21 6:17 bug#27437: Source downloader accepts X.509 certificate for incorrect domain Leo Famulari @ 2017-06-21 10:50 ` Ludovic Courtès 2017-06-22 4:09 ` Leo Famulari 2017-06-22 15:33 ` Mark H Weaver 0 siblings, 2 replies; 17+ messages in thread From: Ludovic Courtès @ 2017-06-21 10:50 UTC (permalink / raw) To: Leo Famulari; +Cc: 27437 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’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-21 10:50 ` Ludovic Courtès @ 2017-06-22 4:09 ` Leo Famulari 2017-06-22 7:57 ` Ludovic Courtès 2017-06-22 15:33 ` Mark H Weaver 1 sibling, 1 reply; 17+ messages in thread From: Leo Famulari @ 2017-06-22 4:09 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 27437 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-22 4:09 ` Leo Famulari @ 2017-06-22 7:57 ` Ludovic Courtès 2017-06-22 16:16 ` Leo Famulari 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2017-06-22 7:57 UTC (permalink / raw) To: Leo Famulari; +Cc: 27437 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’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-22 7:57 ` Ludovic Courtès @ 2017-06-22 16:16 ` Leo Famulari 0 siblings, 0 replies; 17+ messages in thread From: Leo Famulari @ 2017-06-22 16:16 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 27437 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-21 10:50 ` Ludovic Courtès 2017-06-22 4:09 ` Leo Famulari @ 2017-06-22 15:33 ` Mark H Weaver 2017-06-22 16:11 ` Leo Famulari 2017-06-22 21:45 ` Ricardo Wurmus 1 sibling, 2 replies; 17+ messages in thread From: Mark H Weaver @ 2017-06-22 15:33 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 27437 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-22 15:33 ` Mark H Weaver @ 2017-06-22 16:11 ` Leo Famulari 2017-06-22 19:12 ` Ludovic Courtès 2017-06-22 21:30 ` ng0 2017-06-22 21:45 ` Ricardo Wurmus 1 sibling, 2 replies; 17+ messages in thread From: Leo Famulari @ 2017-06-22 16:11 UTC (permalink / raw) To: Mark H Weaver; +Cc: 27437 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-22 16:11 ` Leo Famulari @ 2017-06-22 19:12 ` Ludovic Courtès 2017-06-23 0:45 ` Mike Gerwitz 2017-06-22 21:30 ` ng0 1 sibling, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2017-06-22 19:12 UTC (permalink / raw) To: Leo Famulari; +Cc: 27437 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’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-22 19:12 ` Ludovic Courtès @ 2017-06-23 0:45 ` Mike Gerwitz 2017-06-23 9:31 ` Ludovic Courtès 0 siblings, 1 reply; 17+ messages in thread From: Mike Gerwitz @ 2017-06-23 0:45 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 27437 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-23 0:45 ` Mike Gerwitz @ 2017-06-23 9:31 ` Ludovic Courtès 0 siblings, 0 replies; 17+ messages in thread From: Ludovic Courtès @ 2017-06-23 9:31 UTC (permalink / raw) To: Mike Gerwitz; +Cc: 27437 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’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-22 16:11 ` Leo Famulari 2017-06-22 19:12 ` Ludovic Courtès @ 2017-06-22 21:30 ` ng0 1 sibling, 0 replies; 17+ messages in thread From: ng0 @ 2017-06-22 21:30 UTC (permalink / raw) To: Leo Famulari; +Cc: 27437 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-22 15:33 ` Mark H Weaver 2017-06-22 16:11 ` Leo Famulari @ 2017-06-22 21:45 ` Ricardo Wurmus 2017-06-22 22:32 ` Marius Bakke 2017-06-23 3:24 ` Leo Famulari 1 sibling, 2 replies; 17+ messages in thread From: Ricardo Wurmus @ 2017-06-22 21:45 UTC (permalink / raw) To: Mark H Weaver; +Cc: 27437 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-22 21:45 ` Ricardo Wurmus @ 2017-06-22 22:32 ` Marius Bakke 2017-06-23 3:24 ` Leo Famulari 1 sibling, 0 replies; 17+ messages in thread From: Marius Bakke @ 2017-06-22 22:32 UTC (permalink / raw) To: Ricardo Wurmus, Mark H Weaver; +Cc: 27437 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-22 21:45 ` Ricardo Wurmus 2017-06-22 22:32 ` Marius Bakke @ 2017-06-23 3:24 ` Leo Famulari 2017-06-23 7:29 ` Ricardo Wurmus 1 sibling, 1 reply; 17+ messages in thread From: Leo Famulari @ 2017-06-23 3:24 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: 27437 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-23 3:24 ` Leo Famulari @ 2017-06-23 7:29 ` Ricardo Wurmus 2017-07-27 12:29 ` Ludovic Courtès 0 siblings, 1 reply; 17+ messages in thread From: Ricardo Wurmus @ 2017-06-23 7:29 UTC (permalink / raw) To: Leo Famulari; +Cc: 27437 [-- 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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-06-23 7:29 ` Ricardo Wurmus @ 2017-07-27 12:29 ` Ludovic Courtès 2017-07-27 19:34 ` Ricardo Wurmus 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2017-07-27 12:29 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: 27437 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’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#27437: Source downloader accepts X.509 certificate for incorrect domain 2017-07-27 12:29 ` Ludovic Courtès @ 2017-07-27 19:34 ` Ricardo Wurmus 0 siblings, 0 replies; 17+ messages in thread From: Ricardo Wurmus @ 2017-07-27 19:34 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 27437-done 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2017-07-27 19:35 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-06-21 6:17 bug#27437: Source downloader accepts X.509 certificate for incorrect domain Leo Famulari 2017-06-21 10:50 ` Ludovic Courtès 2017-06-22 4:09 ` Leo Famulari 2017-06-22 7:57 ` Ludovic Courtès 2017-06-22 16:16 ` Leo Famulari 2017-06-22 15:33 ` Mark H Weaver 2017-06-22 16:11 ` Leo Famulari 2017-06-22 19:12 ` Ludovic Courtès 2017-06-23 0:45 ` Mike Gerwitz 2017-06-23 9:31 ` Ludovic Courtès 2017-06-22 21:30 ` ng0 2017-06-22 21:45 ` Ricardo Wurmus 2017-06-22 22:32 ` Marius Bakke 2017-06-23 3:24 ` Leo Famulari 2017-06-23 7:29 ` Ricardo Wurmus 2017-07-27 12:29 ` Ludovic Courtès 2017-07-27 19:34 ` Ricardo Wurmus
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).