No, this proprietary software.

Marcus, please decide whether we should apply them. Afaics, the options are not
the standard ones we use. The strange G_GSIZE_FORMAT macros look strange, we
better cast to int or use "%zd". Using the unused attribute to mark unused args
is not portable; better we access them (void)foo;

Here's the link to the GTK+ 3 transition:

D129: 294_0002-Add-gseal-gtk-compat.h-from-gedit.patch

Compat with older GTK+

D130: 293_0001-Make-DSEAL-safe.patch

This still affects 0.8.0.

I understand (and exactly it is why I do not want use some weak RNG but use
something robust in crytsetup).

No, this would violate the design of the RNG. It is already hard enough to come
up with good random and we don't want to weake it anymore.

No the warning will stay. I will add a comment to show that this is an optional
part of the API.

I see, so there is no immediate action needed and I can release a full
features libassuan 2.0.0 even without this feature, and in a future version
this warning will be gone, right?

It is liklely that we remove gpgkey2ssh entirely. It used to be a test program
for the gpg-agent implementation. I never used it.

The libassuan provides this feature and we don't want to remove it. GnuPG
however does not use it antmore. In fact, in the development branch we are
working on replacing all use of stdio by our estream code which features an
fopencookie like fucntion and thus it will be possible to use features like
logging to sockets aso on system without a native funopen/fopencookie.

In card edit it is:

Changed in all branches (svn rev 5256).
The prompts are now:

Taking a look at the code, it would require to adjust

May I ask for the status? Seems, there were no objections.

Agreed.

Implemented since 1.0.2

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,