The protection used in the exported key used a different iteration
count than given in the S2K field. Thus all OpenPGP keys exported
from GnuPG 2.1-beta can't be imported again. Given that the actual
secret key material is kept in private-keys-v1.d/ the can be
re-exported with this fixed version.
Since 2009-12-08 gpg was not able to find email addresses indicated
by a leading '<'. This happened when I merged the user id
classification code of gpgsm and gpg.
2011-04-20 Marcus Brinkmann <mb@g10code.com>
* command.c (cmd_import_key): Release key from failed import
before converting openpgp private key in the openpgp-private-key
case.
To better cope with round robin pooled A records like keys.gnupg.net
we need to keep some information on unresponsive hosts etc. What we
do now is to resolve the hostnames, remember them and select a random
one. If a host is dead it will be marked and a different one
selected. This is intended to solve the problem of long timeouts due
to unresponsive hosts.
The code is not yet finished but selection works.
This helps in the case of an unknown key algorithm with a corrupted
packet which claims a longer packet length. This used to allocate the
announced packet length and then tried to fill it up without detecting
an EOF, thus taking quite some time. IT is easy to fix, thus we do
it. However, there are many other ways to force gpg to use large
amount of resources; thus as before it is strongly suggested that the
sysadm uses ulimit do assign suitable resource limits to the gpg
process. Suggested by Timo Schulz.
Without Libgcrypt 1.5 is was not possible to use ECC keys. ECC is
major new feature and thus it does not make sense to allow building
with an older Libgcrypt without supporting ECC.
Also fixed a few missing prototypes.
This is not a part of pin pad support series of mine.
As I found the bug while I am preparing the patches, I report this.
As CCID protocol is little endian, wLangId of US English = 0x0409
is represented as two bytes of 0x09 then 0x04.
It is really confusing that the code like following is floating
around:
pin_verify -> wLangId = HOST_TO_CCID_16(0x0904);
But, it is 0x0409 (not 0x0904). It is defined in the documentation:
http://www.usb.org/developers/docs/USB_LANGIDs.pdf
and origin of this table is Microsoft. We can see it at:
http://msdn.microsoft.com/en-us/library/bb165625%28VS.80%29.aspx
Yes, it would be better not to hard-code 0x0409. It would be better
to try current locale of the user, or to use the first entry of string
descriptor. I don't have time to implement such a thing...
This was a regression in 2.1 introduced due to having the agent do the
signing in contrast to the old "SCD PKSIGN" command which accesses the
scdaemon directly and passed the hash algorithm. The hash algorithm
is used by app-openpgp.c only for a sanity check.
Using "gpgsm --genkey" allows the creation of a self-signed
certificate via a new prompt.
Using "gpgsm --genkey --batch" should allow the creation of arbitrary
certificates controlled by a parameter file. An example parameter file
is
Key-Type: RSA
Key-Length: 1024
Key-Grip: 2C50DC6101C10C9C643E315FE3EADCCBC24F4BEA
Key-Usage: sign, encrypt
Serial: random
Name-DN: CN=some test key
Name-Email: foo@example.org
Name-Email: bar@exmaple.org
Hash-Algo: SHA384
not-after: 2038-01-16 12:44
This creates a self-signed X.509 certificate using the key given by
the keygrip and using SHA-384 as hash algorithm. The keyword
signing-key can be used to sign the certificate with a different key.
See sm/certreggen.c for details.
This solves a problem where ccid was used, the card unplugged and then
scdaemon tries to find a new (plugged in) reader and thus will
eventually try PC/SC over and over again.
Also added an explicit --kill command to gpgconf.
The import test imports the keys as needed and because they are
passphrase protected we now need a pinentry script to convey the
passphrase to gpg-agent.
The basic network code from http.c is used for finger. This keeps the
network related code at one place and we are able to use the somewhat
matured code form http.c. Unfortunately I had to enhance the http
code for more robustness and probably introduced new bugs.
Test this code using
gpg --fetch-key finger:wk@g10code.com
(I might be the last user of finger ;-)
