User Details
- User Since
- Mar 27 2017, 4:49 PM (401 w, 1 d)
- Availability
- Available
Dec 15 2012
Finishing things up now.
Note that this implies setting Host: properly as well
Dec 2 2012
Taking
Jan 19 2012
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.
Dec 28 2011
(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.
Dec 15 2011
Ok, fixed on 1.4, 2.0, and master.
Aug 11 2011
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).
Apr 4 2011
I suppose if we wanted to be needlessly pedantic, RFC-4880 actually specifies
JFIF (not JPEG as a whole).
Mar 26 2010
Aug 24 2009
I had a go at doing this in sections. I used:
Aug 12 2009
Did 1.4. Will do 2.0 shortly, after a bit of testing.
Aug 11 2009
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.
Jun 1 2009
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.
May 29 2009
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
May 28 2009
Change 5028 for 2.0.
May 26 2009
Change 5024 for 1.4. Will do 2.0 shortly.
May 22 2009
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).
May 21 2009
Ah, never mind. I found a key (ACCFFAE2) that nicely duplicates the problem.
May 20 2009
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?
Oct 3 2008
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).
Oct 27 2007
Looks like gpgkeys_curl.exe is being run instead of gpgkeys_hkp.exe. I'm pretty
sure this fixed it:
Jul 19 2007
This is already fixed.
Jul 18 2007
Fixed for 1.4.8.
Jul 7 2007
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!
Jun 7 2007
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.
Mar 7 2007
Fixed in 1.4 (r4445). I haven't integrated the fix to 2.0 yet.
Dec 14 2006
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.
Dec 3 2006
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".
Nov 6 2006
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
Oct 20 2006
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.
Oct 6 2006
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.
Aug 4 2006
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.
Jul 27 2006
Is fixed.
Duplicate of 638
Jul 21 2006
Done, thanks!
Jul 13 2006
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).
Jun 10 2006
Fixed.
Jun 6 2006
May 17 2006
This works correctly in 1.4.3.
May 8 2006
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.
Apr 23 2006
Not a bug.
Apr 22 2006
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.
Mar 8 2006
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
Jan 11 2006
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.