Well, should be implemented.

Marcus, please apply

This is not possible - pinentry is called from a background task and thus needs
a way to take over the current terminal. A simple command line input would be
too easy to fake by data to be processed. If you really want this, please write
your own pinentry.

Done in trunk (2.1), rev 5233

I put it in (r213)

Implemented for dirmngr. That will go into dirmngr 1.1.0.

Applied (rev 1024). Thanks.

D117: 269_diff

Please find a minor patch attached. It fixes the formatting of the headline
(command should be all-uppercase). It further introduces a few formatting
requests (e.g. don't hyphenate the filename or the reference to gtk-options.

Commited to 2.0 and trunk, rev. 5224.
Now for dirmngr.

Okay, I implemented that for gpgsm:

That is a hard to fix problem. We don't have the infrastructure to merge
keyserver requests. Adding this to gpg will be quite some work. A tentative
plan to implement this would require a local daemon to cache requests (e.g.
enhancing dirmngr) and to rework gpg to allow for asynchronous updates.

Dear Mr. Koch,

From my investigation the only workaround seems to be the no-honor-keyserver-url
option. What I could imagine is, to test, if the given keyserver pref of a key
is equal to the specified preferred keyserver and delay this key processing and
process it with all other keys without keyserver prefs. However this won't solve
the problem completely, as all other keys would still be processed one after the
other (which BTW sounds reasonable to me).

Thanks. Commited to the SVN -r 1023.

After talking to Arthur, the author of the manual page, the manual page is
provided under the GNU General Public license version 2 or (at your option) any
later version.

Well, it will be some work to parse the description of policyConstraints and
policyMappings and see who it fits into the GnuPG system.

I don't think this is a proper solution. --default-key has the same problem as
--local-user. What we can do is to fail if a key has been specified in a
non-unique way. Selecting one by chance is a Bad Thing.

These bug reports are sometimes mixing two different issues: The
debian-keyring and r/o keyrings for other purposes.

Thanks. Commited to branches/STABLE-BRANCH-2-0/.

Dear Mr. Koch,

Dear Mr. Werner,
thank you for your prompt replay. I will try out your workaround to solve the issue.
Thanks a lot!

(I have not looked up the description of these policyConstraints.)

Hi Werner,

Hi Werner,

Hi Werner,

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.