We don't support the keypad with pcscd.

We can implement that in 2.1 after having replaced the current keyring based DB
with the Keybox based one. The latter is far more efficient and does not
require sequential scans all the time. Some breakage will anyway happen and
thus a new selection strategy, i.e. a well defined one, won't harm either.

Wen can look into this during the development of 2.1.

We will do this in 2.1 and maybe backport it later

We need to review the purpose of gpgkey2ssh. It might be easier to integrate
this into one of the other tools.

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

Agreed for the manual page. We will think about this.

I leave this decision to you. I agree to the reporter, that everything is a bit
"wildly" ordered atm. However, I cannot speak for an unexperienced user. I've
asked the reported for feedback/his opinion.

That would be hard to implement. Consider that an alpahbetic order makes most
sense only to English speaking users, whereas others will likely use the
translated description.

Sorry, this was the wrong report. #917 is still open.

Seems to has been missed to be synced. Issue is still there.

Hi Marcus,
On Thu, Aug 13, 2009 at 01:29:26PM -0000, Marcus Brinkmann via BTS wrote:

Marcus Brinkmann <marcus@g10code.com> added the comment:

I don't see a reason to apply the patch, there are no po files generated for
pinentry. Is this to sync our copy of gtksecentry of another project? I
checked krb5-auth-dialog in Ubuntu, and it does not have this patch.

The patch is in krb5-auth-dialog's upstream. Ubuntu is lagging as
usual, Debian has it.

I don't see a reason to apply the patch, there are no po files generated for
pinentry. Is this to sync our copy of gtksecentry of another project? I
checked krb5-auth-dialog in Ubuntu, and it does not have this patch.

Quite right, claws actually does invoke AC_SYS_LARGEFILE.

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.

Applied to 5089. Thanks.

An admin saw this suggestion in front of a user and got annoyed
that the recommendation

"the trustdb is corrupted; please run \"gpg --fix-trustdb\".\n") );

in tdbio_invalid(void) gnupg-2.0.12 did not work.

Done for 2.0 in svn r5082; will also be packaged with gnupg 1.4.10.

We can't print an error message because that would let gpg treturn with an error
code and lead to problesm with scripts which assume the current way of doing
things. A warning is possible but Unix tools generally don't do that.

For obvious reasons the mailto scheme is not very useful. It is not even build
by default; you have to use ./configure --enabe-mailto. OTOH, I see that a way
to batch up keys for later retrieval is a nice feature - it should hwoever not
be limited to the mailto scheme.

UID are expected to be UTF-8, IDN conversion should be done by the MUA.

Will be released with 1.4.10.

The first part is not easy to fix and would require quite some rework. I don't
think this is justified.

Enter a "?" on the prompt and it will show you the valid characters.
We can't change this right now because this would break all translations.

Done for 2.0.13:

This looks pretty much like a pc/sc problem. Please shutdown pcscd and use the
internal CCID driver. With PC/SC we don't have any control over the USB - we
don't even know what this is.

More info:

• scd killscd works when in the replug-without-hibernate case, for hibernate, a restart of pcscd is needed (probably not a scd problem).
• when I don't issue any commands to scd while the reader is unplugged, I can re-plug it anywhere (same or different usb port) and scd recognises this as a USABLE->ACTIVE->NOCARD->USABLE transition chain
• when I issue a SERIALNO command while the reader is unplugged, I get "Card Error" back (sitenote: shouldn't that be a ERR_NO_CARD_READER?) and that one sticks until a KILLSCD.
• this is not the case for other commands (tested: GETINFO version).

Marcus, please apply that.

Any chance this gets applied?

D99: 234_0001-Don-t-mark-properties-as-translatable.patch

Thanks, I put it in (rev206).

Marcus, I think we can close this now.