Which version of _GnUPG_ are you using?

Andre, can we close this bug?

1.9.0 has been released.

I have noced that you added the C++ interface. Thanks.

I see. Let's get back to this after the release of 1.9

The keyserver helpers programs which are the cause for some not too useful error
messages have been removed from 2.1. Thus the error messages are different and
might be better - at least the dirmngr, responsible for fetching keys, can
create a detailed log file.

I tagged this as wontfix because we won't do any chnages to 2.0 anymore, its
EOLed for the end of the year.

Please feel free to re-open this bug if you experience such problems asl with
2.1.19 or higher.

Thanks for reporting.

Hi!

re 1. It is pretty new that the release notes are linked to the NEWS files. We
have a script to do this but it still needs a manual build. Have not yet done
that. For 10 days or so we again have an autobuilder for the website which can
take over the manual build step. Needs to be done. I keep this bug open to
track this.

re 2. The labels attached to the branches aused more confusion than they helped.
The plan is to remove 2.0 entirely (its EOF is in 9 months). The website
should only prominently only show the stble version. And yes, "modern" has been
stable as well.

re 3. To avoid confusion 1.4 has mostly been removed from the frontpage. Same
reason as above. However, somewhere we need to state this.

What about

gpgme_get_dirinfo ("agent-socket")

? For testing you can use

GNUPGHOME=/foo/bar gpgme/tests/t-engine-info 2>&1 | grep agent-info

Please do not post files in closed formats like Microsoft word. We will only
look at reports in a plain text format.

From your description it looks more like a build problem because Libgcrypt is
already part of Ubuntu and installing a different version is possible but you
need to get some things right. In general I would suggest to write to
gcrypt-devel@gnupg.org

Can you rebuild using -O0 -g and try to get a back trace again. That might be
helpful.

We also have a discussion of the mailing list. It does currently not make sense
to continue here.

The problem of NFS mounted home directories is _real_ and we have a solution for
this which is better than the old redirection hack.

The problem with too long socket names is not severe and has been around for
decades (for other software and 14 years for GnuPG). There are workaround and
/run/user also solves this.

I proposed a change which does not even require --create-socketdir. There was
no comment on this and thus I will push that now so that we can do a real life test.

I concur. We should disable the Python tests for gnupg versions < 2.1.12 (which
is about a year old)

Duplicate of T1060

2.1 has the option --unwrap to just this.

Implemented in 2.1.19

Oh yes, then we should include NetBSD at least into the nPth and libgpg-error
builds.

Our jenkins has no problems building nPth for OpenBSD 6.0.
wiz: Do you think that NetBSD (x86 I assume) is much different than OpenBSD so
that we would benefit from adding NetBSD to our Jenkins builds?

gniibe: Do you have time to look into this?

The log indeed does not match the former gpgme2.trace.

I would try to switch to gpgme 1.8.0 so see whether you can still reproduce the
problem.

Given that 2.0 will reach EOL in 9 months I don't think it is worth to backport
and test that patch.

Thanks. So gpgsm is started but terminates before it can actually receive a
command from GPGME. Can you please add

log-file /bar/bar/gpgsm.log
debug 1024
verbose

to ~/.gnupg/gpgsm.conf and run the test again. Please post the log again.

Justus: I told you several times that we are not going to change working code
for no good reason. Even if your hack (I call it a hack because it does not
work with getsockname) would make it, it does not solve the major problem: The
inability of creating sockets on certain file systems. THAT is the major reason
why we moved to /var/run.

Can you provide a plain C test program to show the effect or, maybe easier a
GPGME trace file running your program?

GPGME_DEBUG=9:gpgme.trace: YOURTESTPGM

See tests/run-genkey --set-primary on how to use it.

commit 421ddd1 implements that for 1.9.0.

To debug this you need to run mutt like this:

GPGME_DEBUG=9:gpgme.trace: mutt

The trace file will be pretty verbose but contains everything GPGME sees from
the engine.

What do you mean by "maintainig a GPGME library"? A language binding or an
implementaion similar to GPGME?

I close this one. An implementation is already in master.

Duplicate of T2819

Done with commit 35023f3.

I modified the patch slighly, added docs and a --from-file to run-keylist.
You may want to add a C== and Qt interface.

Are they sending ASCII armored files (those with "-----BEGIN PGP MESSAGE-----")
of binary data?

They might have used the -t (--textmode) option and removed that.

But more likely is that this is one of the usual CR,LF problems. For example
when using FTP, and sending binary data, it is important to switch to binary
mode first. WIthout looking at the data it is hard to help.

FYI this is:
Skip tests if GnuPG is too old.
Use 'gpg-agent --allow-loopback-pinentry' if applicable.

Shall I look into this?

So this is about the new Python binding.
I would suggest not to build tye python support on systems with the old 2.0.24.
Note that 2.0 will reach EOL in 9 months.

Okay. So the actual cause is that we print data for a key (usage, expire, and
possible more) which we should not do. That data comes from self-signatures and
those can't be verified because we have a time warp. That should be the same as
with invalid self-signatures - what do we do in that case?

What are the reasons that expredate is not valid?
merge_keys_and_selfsig() not called for sure, Anything else?

Fixed with commit 69c521d.
You can reconfigure your server. Thanks.

What is this Apache thing ;-). Frankly, I don't have one running and it would
be easier if you can remove it from testkolab. The current Windows versions
should not have the problem anyway because warning alerts are skipped in ntbtls.
For gnutls I have a fix ready.

Thomas: Is there any way how I can reproduce this now that you changed the
configuration of testkolab?