Due to time constraints, the 0.9 series of GpgOL is no longer supported.
I am sorry for this inconvenience. Gpg4win/2 will soon be released featuring a
heavily rewritten GpgOL.

Attestation has been removed in 0.10.

Due to time constraints, the 0.9 series of GpgOL is no longer supported.
I am sorry for this inconvenience. Gpg4win/2 will soon be released featuring a
heavily rewritten GpgOL.

This is so that we can use the OOM to read the body.

This is still on my todo list.

Due to time constraints, the 0.9 series of GpgOL is no longer supported.
I am sorry for this inconvenience. Gpg4win/2 will soon be released featuring a
heavily rewritten GpgOL.

This has been implemented.

Can't be done for 2.0.10. Will be considered later.

This has been discussed in the past but I might reconsider. Won't happen for
2.0.10, though.

The 0.9 series is not anymore supported.

Done in 4888. For scdaemon this is a half second and for gpg-agent every third
second.

Thanks, I put the version in #975 into SVN.

Duplicate of T975

This looks pretty much like an autoconf bug. However, a broken instalaltion of
a compiler is a bad sign for a system, so one might even be thabnkful for such a
message ;-).

Note that there is another fr.po update as T975.

configure script of libgcrypt (and libgpg-error) does not run without a C++
compiler installed, throwing "C++ compiler fails sanity check". However, when
manually "fixing" the configure script to not exit when it can't find a compiler
and instead continue, libgpg-error and libgcrypt configure and build properly,
even without a C++ compiler.

Thanks. Available in SVN rev 189.

Admin PIN via pinpad are enabled since 2.0.9.

Works fine for me with gpgme_op_verify, which actually runs the gpgme -o command
as you gave it. Did you rewind the output data object before trying to
read the data?

Marcus: Can you please check whether we can easily add this to gpgme_op_decrypt?

I am sorry, but we won't add such a feature for these reasons:

Fixed in my working copy.

Background info: My e-mail program is currently calling gpg via fork() and
exec() and is thus very GnuPG version dependent. It does not create such
messages, but can display them. Trying to get rid of the version dependency,
I've tried to switch to GPGME and stumbled about a test message I've received
years ago. Unfortunately the header lines do not mention what mail program was
used for sending.

Use
--trust-model always

I was not aware that such OpenPGP messages are actually used. We need to see how
to implement that.

Checking the text from T960 (wk on Oct 13 2008, 10:45 AM / Roundup):
I think the text is a significant improvement.

Okay, I change the man page to read:

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).

I'm happy to assign copyright for this patch to the FSF, if that's needed.

awaiting backport to 1.4.