Finishing things up now.

Note that this implies setting Host: properly as well

Taking

I think this makes sense. It's not a hard change. Way back when, I did something similar for trust_model -
it's stored in the version record and if gpg detects that the current model does not match what is encoded in
the header, it marks the trustdb as pending_rebuild.

(Understood there are no immediate plans for a release, but if/when we do have
one, the change will be ready)

Change committed to 1.4, 2.0, and master.

Ok, fixed on 1.4, 2.0, and master.

I think this is fine. I originally wrote the code to send short keyids as pksd
couldn't properly handle long keyids or fingerprints. As pksd is now dead, and
sks properly handles this, I think it is reasonable to send the longest ID
appropriate (send fingerprints if we have them, long keyids if we have them, and
short keyids if we must).

I suppose if we wanted to be needlessly pedantic, RFC-4880 actually specifies
JFIF (not JPEG as a whole).

I had a go at doing this in sections. I used:

Did 1.4. Will do 2.0 shortly, after a bit of testing.

If this is pursued, I suggest doing it as a subsystem external to GnuPG. GnuPG
can generate keyserver information files (via --keyserver-options
use-temp-files). An external program can gather these files and manage them
however it likes, then pass them to the keyserver helper programs when it is
ready to.

The internals are already set for multiple keyservers (opt.keyserver is a
strlist, etc.) I had to implement it for the auto-key-retrieve feature, which
does support multiple servers.

Good idea. I think an adaptation of that code will do nicely. I think what is
needed here is a pass through that code, which almost always returns UTF8, then
a pass through utf8_to_native and then native_to_utf8. This is a lot of
manipulation, but string_to_utf8 may not return UTF8 if the user ID is coded
very badly, and the LDAP server will reject anything that isn't UTF8

Change 5028 for 2.0.

Change 5024 for 1.4. Will do 2.0 shortly.

Interestingly enough, it's no longer the default in libcurl. We'll have to do
it for both the libcurl and emulation cases.

I think that if the primary key is expired, the subkeys should be treated as
expired as well. The only thing that makes the subkey valid in the first place
is the binding signature - which was issued by the expired primary key.

This is the occasionally-requested "--unwrap" command which would stop
processing after a single layer of the file. I.e. convert Enc(Sign(data)) to
Sign(data).

Ah, never mind. I found a key (ACCFFAE2) that nicely duplicates the problem.

Could you attach a copy of the public key you're having a problem with to this
bug? If you don't want to reveal that key for whatever reason, could you
generate another one with the 'é' character that shows the same problem?

Closing.

I like the idea, but I'd implement it slightly differently (nothing major -
there are a few unnecessary #includes, and I'd rather protect pct_expando in
pct_expando rather than rely on the caller to submit sane arguments).

Looks like gpgkeys_curl.exe is being run instead of gpgkeys_hkp.exe. I'm pretty
sure this fixed it:

This is already fixed.

Fixed for 1.4.8.

This is done. --force-v3-sigs (including --pgpX) disables all v4 sig features.

This is not a bug, though it's certainly annoying. The problem is that
pgp.mit.edu has a corrupt copy of that key. GPG can handle the corruption, but
the algorithm for de-corrupting the key is somewhat expensive, essentially
requiring each signature on a user ID to be compared to every other signature.
(n-1)^2

Taking bug.

Fixed. Looks like I missed one when I factored out the common code. Thanks!

I think this is good, but doesn't go far enough. I'm thinking that if
force_v3_sigs is set (either directly or via --pgpX commands), then we should
allow that to override all of policy URLs, notations, and keyserver URLs. Right
now, it only overrides expiration dates, which is inconsistent (overriding some
v4 features, but not all). I'll see what I can make for that.

Fixed in 1.4 (r4445). I haven't integrated the fix to 2.0 yet.

Is this just an issue of escaping the spaces? Given that the problem seems to
happen across two platforms (Win2k and Fedora Linux) that would be a reasonable
explanation.

I believe I have a fix in svn now. It works on my 10.4 box. It should
work on 10.3 and 10.2, but may not work on earlier versions.

Maybe better just to redirect to http://www.gnupg.org ?

I've implemented this one as --passphrase-repeat. Users may set this to however
many repeats they feel will help them remember the passphrase. If they make an
error, GPG will start over. It defaults to 1 of course, which is the old behavior.

I'm going to close this now. GPG is doing as well as it can given the vagaries
of what HKP servers return. Unfortunately, there is no readily parsable
difference between "server failure", "key not found", or even "this isn't a
keyserver at all".

I'm going to have to revert this and reopen the bug for discussion. Even the
SKS servers return HTML for a genuine key-not-found response. It is
inappropriate for gpg to complain in that case

Done.

The HTML response is only from the old pks keyservers, and there aren't any of
them left (the old keyservers were the ones that destroyed subkeys). Still,
I'll add something like this just to be sure.

Actually it would be best to always write the v4 fingerprint (or 16 digit keyid
for v3) and let the gpgkeys_* handle both, but so far no keyserver can actually
make use of a full fingerprint, so there is no need to do this work now.

I'm afraid I don't understand what the bug is here. The statement
"The keys which were submitted via gpg obviously lacked the 0x" is not meaningful.

Is fixed.

Duplicate of 638

Done, thanks!

Have you modified the code in some way? I can't duplicate
the failure, and can't see, given the code, how this could
even be possible.

Fixed, thanks! I also took care of a similar potential
problem in gpgkeys_ldap.c (it wasn't a problem as the
delimiter was 7-bit clean, but best to fix it anyway).

Fixed.

No bug here.

This works correctly in 1.4.3.

From: "Woody Weaver -X \(wooweave - Links Technology at Cisco\)" <wooweave@cisco.com>
To: <bug-any@bugs.gnupg.org>, <gnupg-hackers@gnupg.org>,

<gnats-admin@trithemius.gnupg.org>

Cc:
Subject: RE: gnupg/651
Date: Mon, 8 May 2006 15:32:48 -0400

This is not a bug. We do not support that keyserver over
HKP, only LDAP. It is true we used to in 1.4.2 (and in fact
you can reenable such support in 1.4.3 by building with
--enable-old-keyserver-helpers), but this required GPG to
parse the HTML response which varied slightly between
different keyservers. As new keyserver types came online,
we had to detect their own flavor of that HTML and adapt to
it - utterly unscalable. Newer keyservers either use LDAP
or (like pgp.mit.edu) use a consistent machine-readable output.

Not a bug.

From: Gilbert Fernandes <gilbert.fernandes@club-internet.fr>
To: bug-any@bugs.gnupg.org
Cc:
Subject: Re: gnupg/646
Date: Sat, 22 Apr 2006 20:14:24 +0000

Fixed for 1.4.4. Just comment the #include <curl/curl.h>
out for 1.4.3.

There is a false premise here. You cannot parse the output
of GnuPG as we will gleefully change it in the future and
break your script. The only way to safely use GnuPG from a
script is via the --status-xxx interface, which will not
change. See the file doc/DETAILS.

From: David Shaw <dshaw@jabberwocky.com>
To: John Schofield <schof@dakim.com>
Cc: bug-any@bugs.gnupg.org
Subject: Re: gnupg/614
Date: Wed, 8 Mar 2006 13:49:36 -0500

This has already been fixed for 1.4.3

hkp and http are in fact two different and incompatible
schemes. If you wish to discuss this, please take it to the
gnupg-users or gnupg-devel mailing lists.