gpg port should be 80 not 11371

Bug #682995 reported by Ian Booth on 2010-11-30
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself

Bug Description

See bug 615788 for some context. That issue was fixed but the user went on to say that:
I think this should be reopened (I don't have permissions to reopen the original bug for ubuntu-website, so I reopened for launchpad instead - sorry for the hassle). This issue is not solved. The issue is that the *default* port 11371 used for the keyserver is blocked in most corporate environments (like mine). Furthermore, the error messages from Synaptic and add-apt-repository are a fairly generic "can't retrieve repository key" and "can't connect to keyserver" respectively (I'm paraphrasing). This is bad. All these problems could be fixed by changing the default to something less likely to be blocked, like 443, or perhaps 80. Now that I think about it, this would not only have to happen on the server side (which has already happened for port 80), but also on the client side. Maybe apt and/or synaptic should be added to this bug?

So the gpghandler.port config key for Launchpad could be changed from 11371 to 80?

Gary Poster (gary) wrote :

This is much bigger than Launchpad. AFAICT, the default and original hkp port, as defined in all gpg clients, is 11371. For the generically smooth operation behind firewalls that the bug seems to describe, all gpg clients would need to change these defaults, and then all hkp servers would need to adjust to the new defaults. I would be very surprised to see this happen.

gpghandler.port just changes the publicized HKP port on Launchpad web pages. Does that really accomplish much in the way of the goals here?

Changed in launchpad-foundations:
status: New → Incomplete
Martin Spacek (mspacek) wrote :

I agree, this seems unlikely to happen. In comparison, it only took a day for our network guys to open up port 11371 for me :)

What's bad are the generic network error messages that Synaptic and add-apt-repository emit when the port is blocked. Neither really give a hint that it might be a port problem. If at least they reported what port they're trying to connect on, that would give the user a much chance of guessing that it's a firewall problem.

Gary Poster (gary) on 2010-12-06
Changed in launchpad-foundations:
status: Incomplete → Won't Fix
Gary Poster (gary) wrote :

OK, I debated on what to do about this bug. I decided on Won't Fix here, and filing a bug for you against synaptic. I'm still not sure that's quite the right thing to do, but maybe the synaptic folks will have a better idea than I.

Gary Poster (gary) wrote :

I reopened bug 615788 for Synaptic with a comment, instead of filing a new bug.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers