Hi All,
Someone reported difficulty with retrieving 0xEE8CBC9E886DDD89 from the key servers. It seems this is only affecting some of the keyservers (but I don't know which ones because load-balancing).
I was able to reproduce it, but not consistently.
$ gpg --recv-key A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 gpg: packet(13) too large gpg: read_block: read error: Invalid packet gpg: no valid OpenPGP data found. gpg: Total number processed: 0
This error seems suspiciously similar to this sks-keyserver bug[0].
If anyone has any ideas of how we should troubleshoot or fix this, that'd be helpful.
- Matt
[0] https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
On Thu, Jan 31, 2019 at 11:47:09PM +0000, Matthew Finkel wrote:
Someone reported difficulty with retrieving 0xEE8CBC9E886DDD89 from the key servers. It seems this is only affecting some of the keyservers (but I don't know which ones because load-balancing).
I was able to reproduce it, but not consistently.
$ gpg --recv-key A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 gpg: packet(13) too large gpg: read_block: read error: Invalid packet gpg: no valid OpenPGP data found. gpg: Total number processed: 0
This error seems suspiciously similar to this sks-keyserver bug[0].
Yes, it seems like it's the the same issue. Someone made an extremely huge key (about 2 MiB in size) with he id 0x4F3F50786C401DCE that has a whole bunch of binary data as its uid.
As a workaround in the meantime until this is fixed, if someone needs the package signing key right now, I uploaded a backup to my website:
https://www.parckwart.de/files/nuclear_waste/tor_deb_archive_signing_key.asc http://45tbhx5prlejzjgn36nqaxqb6qnm73pbohuvqkpxz2zowh57bxqawkid.onion/files/...
Of cource, you shouldn't simply trust the key I give you, but check its validity. It has most of the signatures, like arma's for example, as I downloaded it from an SKS keyserver about a week ago.
Update:
I took a closer look at the key that broke the Tor key with its signature:
pub rsa4096/4F3F50786C401DCE 2015-10-04 [SC] 17F9D6D43CE4DDEE4178548C4F3F50786C401DCE uid Richie ryetschye@web.de uid Richie ryetschye@posteo.ru uid Richie ryetschye@ironcomputing.de uid Richie (IRONCOMPUTING) richie@ironcomputing.de uid Richie (IRONCOMPUTING) richie@irconcomputing.de uid Richie richard.gottschalk@stud.uni-regensburg.de uid Richie (IronComputing KG) richie@ironcomputing.de uid Do not use SKS keyserver sites (no validity checks) <@> uid Do not use SKS keyserver sites (no validity checks) https://bitbucket.org/skskeyserver/sks-keyserver/issues/41
Apparently, someone wants to turn people's attention to this ticket:
https://bitbucket.org/skskeyserver/sks-keyserver/issues/41
Although the more apropriate ticket to link to in this case would be this one:
https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
The problem is basically that anyone can dump a whole bunch of data into the UID field of their key and upload it, which overloads both the keyservers and the PGP clients. I've already sent a mail to Kristian Fiskerstrand (the developer of SKS keyserver), explaining the problem.
On Thu, Jan 31, 2019 at 11:47:09PM +0000, Matthew Finkel wrote:
$ gpg --recv-key A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 gpg: packet(13) too large gpg: read_block: read error: Invalid packet [...] If anyone has any ideas of how we should troubleshoot or fix this, that'd be helpful. [...] [0] https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
Thanks Matt. I've been answering a couple of people a day in #tor who are confused by this issue. As a stopgap, I've changed the instructions page: https://www.torproject.org/docs/debian to point people to a keyserver that doesn't (currently) have this bug.
Ultimately, I wonder if we should start providing a full keyring (text file) that people can download from our website and import for themselves.
--Roger
the keyserver network is, sadly, showing its age. Its flaws have been known within the community for years, and a few proposals have surfaced for offering a replacement, but the sks software is difficult to maintain (idiosyncratic ocaml) and deploying larger changes in a coordinated way across a globally-syncing network is even more difficult. :(
On Mon 2019-02-04 17:00:56 -0500, Roger Dingledine wrote:
Thanks Matt. I've been answering a couple of people a day in #tor who are confused by this issue. As a stopgap, I've changed the instructions page: https://www.torproject.org/docs/debian to point people to a keyserver that doesn't (currently) have this bug.
hm, this documentation is still out of date. modern best practices would not involve using "apt-key add -", but instead use a Signed-By option (see sources.list(5)) that point to an otherwise untrusted curated keyring.
Ultimately, I wonder if we should start providing a full keyring (text file) that people can download from our website and import for themselves.
you can see a good writeup by anarcat here of modern best practices for a debian repository anchored by such a downloaded key:
https://wiki.debian.org/DebianRepository/UseThirdParty
If you want to get even smoother, other projects just ship a *-archive-keyring package directly in debian itself, which enables pretty easy expansion from mainline debian to a third-party repository, without the local user having to do any manual cryptographic verification.
I don't think anyone would object to tor-archive-keyring in debian. If anyone's interested in doing this, please let me know, i'd be happy to provide some guidance on the safest way to do this for versions of debian starting with the current stable ("stretch").
--dkg
On Mon, Feb 04, 2019 at 07:27:32PM -0600, Daniel Kahn Gillmor wrote:
the keyserver network is, sadly, showing its age. Its flaws have been known within the community for years, and a few proposals have surfaced for offering a replacement, but the sks software is difficult to maintain (idiosyncratic ocaml) and deploying larger changes in a coordinated way across a globally-syncing network is even more difficult. :(
On Mon 2019-02-04 17:00:56 -0500, Roger Dingledine wrote:
Thanks Matt. I've been answering a couple of people a day in #tor who are confused by this issue. As a stopgap, I've changed the instructions page: https://www.torproject.org/docs/debian to point people to a keyserver that doesn't (currently) have this bug.
hm, this documentation is still out of date. modern best practices would not involve using "apt-key add -", but instead use a Signed-By option (see sources.list(5)) that point to an otherwise untrusted curated keyring.
That sounds great.
Ultimately, I wonder if we should start providing a full keyring (text file) that people can download from our website and import for themselves.
you can see a good writeup by anarcat here of modern best practices for a debian repository anchored by such a downloaded key:
https://wiki.debian.org/DebianRepository/UseThirdPartyIf you want to get even smoother, other projects just ship a *-archive-keyring package directly in debian itself, which enables pretty easy expansion from mainline debian to a third-party repository, without the local user having to do any manual cryptographic verification.
I don't know if the sysadmin team already considered this, and decided against it for some reason. It sure would be nice having a simpler process for this.
I don't think anyone would object to tor-archive-keyring in debian. If anyone's interested in doing this, please let me know, i'd be happy to provide some guidance on the safest way to do this for versions of debian starting with the current stable ("stretch").
--dkg
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
tor-project@lists.torproject.org
-
Daniel Kahn Gillmor -
Jonathan Marquardt -
Matthew Finkel -
Roger Dingledine