Done and 1.6.1 released

That was added because we have it in master.

Have 'it'? I see it in the tarball of 1.6.

Again: If you do not use the tarball release do not expect that pacthes will

be included. You should never do autoreconf.

We do use the tarball release, and we must patch it to resolve issues you do not
handle as I presented in previous comment.

That was added because we have it in master.

Again: If you do not use the tarball release do not expect that pacthes will be
included. You should never do autoreconf.

We patch your sources mainly because[1], I will be happy to stop autoreconf your
packages, but cannot do this until this and other issues are resolved.

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/files/libgcrypt-1.5.0-uscore.patch?revision=1.1&view=markup

OK, someone already tried to solve it at your side:

tests/Makefile.am

1. Force sequential run of some tests. bench-slope.log: benchmark.log hashtest-256g.log: bench-slope.log

However, from automake manual:

In order to guarantee an ordering between tests even with make -jN, dependencies
between the corresponding .log files may be specified through usual make
dependencies. For example, the following snippet lets the test named
foo-execute.test depend upon completion of the test foo-compile.test:

TESTS = foo-compile.test foo-execute.test
foo-execute.log: foo-compile.log

Please note that this ordering ignores the results of required tests, thus the
test foo-execute.test is run even if the test foo-compile.test failed or was
skipped beforehand. Further, please note that specifying such dependencies
currently works only for tests that end in one of the suffixes listed in
TEST_EXTENSIONS.

Removing the above makes all works in parallel without specific order, which is
nice... unsure why the above was added when there is no real dependency, and
prior to automake-1.13 there was no parallel anyway.

Thanks. I backport it tomorrow.

I just tested with the changes applied to the LIBGCRYPT-1-6-BRANCH head, minus
the sha1.c changes (since the NEON parts weren't there), and it is building and
running fine for me. I assume it should work fine in master given this, and can
test that later if you would like, I'm just currently missing the libgpg-error >=
1.13 dependency for doing that. Thanks for your help getting this fixed up.

Fixed in master with commit 52f7c48.
Can you test it with master or should I do a backport to 1.6 first?

Fixed with commit fb8d8517 for 1.6.1

Backported for 1.6.1

Write a script to do that. It is fairly simple; remember to use --status-fd. I
commonly use awk for such tasks.

Well, I rename it as a reminder for the removal.

Because that automake version is not supported. automake is a maintainer tool
and not a build dependency. If Gentoo has its own policy they are on their own

• it is free software. The tarball release does not have this problem. Or am I

wrong? GIT is developer only and definitely not a release.

Fixed for master with commit cbdc355.

ok then, feel free to close

Not enough for my case.
You can see here the script where I met the need :
https://gist.github.com/aeris/8483548

I have to verify 3 or more signatures, and need to ensure each from a different
signer.
Using gpgv to do this will be a huge hack with multiple trustedkeys.gpg creation
with a single key inside.
Worst and more complicated solution than my current one (with only one sed).

A « --ensure-signer » option with « gpg --verify » will be definitely simpler
and more secure and robust.
Or I miss something in gpgv.

You may want to look at the gpgv tool instead.

that tool will be removed anyway. It was only used as debug aid and not a real
tools. I don't know how it happened that it eventually was installed.

Please report a concrete bug. Due to the often instable libtool developemnt, I
hestitate to change tests which have shown to work on a wide variety of
platforms. Note that we also don't use any new version of libtool but stick to
an old and stable one with our own fixes.

why do you close issues so fast?

"""can you please seek the proper solution?"""

means that I ask to fix build to have proper dependencies between tests to allow
serial or parallel execution. this will work in any version.

Thanks.

Changing category to dismngr to remind about doing a release.

Thist patch does not work because the serial-tests flag is not supported by
older automake versions. The problem has already been discussed at the mailing
lists. See README.GIT on how to use a non-broken automake. I still hope the
utomake folks solve the problem by changing the default. Forcing all projects
to use the new and incompatible parallel tests was a very unpleasant behaviour
of them.

D189: 421_libgcrypt-1.5.0-uscore.patch

D188: 420_libgcrypt-1.6.0-serial-tests.patch

Looks good, compiling with libgcrypt-1.6.0 and creating a signed S/MIME e-mail
with gpgsm works.

No we won't do this. IIIRC, there is another rejected bug report and we also
had a discussion at the ML.

Oh well, backporting is easy enough. Commit id f6bd8ed, will go into 1.6.1.

Will you be so kind and test the attached patch?

D186: 419_dirmngr-pth-fix.patch

With GnuPG 1.x, Enigmail takes care of presenting the passphrase dialog.
With GnuPG 2.x GnuPG does it of its own. For that it spawns a small tool
called pinentry which asks for the passphrase. We actually have several
versions of that pinentry. The one you are using is based on Qt (a toolkit) and
has a limit of 256 bytes for the passphrase. The limit may actually be lower if
you are using non-ascii characters, but I can't see how that value is not
sufficient.

How long is your passphrase and does it contain many non-ascii characters (e.g.
Umlauts)?

First of all, I suggest to use GPGME to access gpg. For an example on how to do
key signing you may want to look at GPA (start with src/gpgmeedit.c).

The gotcha for your problem is --commands-fd N. This will emit additional
status messages on which you have to react. I am sorry, that conrolling gpg is
somewhat complicated -this is due to the hseer amount of options the OpenPGP
protocol provides and of which gpg provides most of them.

For a simple script on how to sign keys, check out tools/signmany. This works
directly if there is only a single user id to sign and falls into gpg's own edit
mode if there are more keys. Sure, you would need a PTY to fully automate it.
But please do use --command-fd or GPGME's gpgme_op_edit API.

Hello, Thank you for your reply.

I used the gpg4win-2.2.1.exe binary which I downloaded from gpg4win.org

The popup I mentioned is the screen that asks me for my password when I try to
open an encrypted mail in my mailbox via thunderbird/enigmail. See the
screenshot. In the newer gpg version this popup is replaced by a prompt screen
that says pinentry and will allow only for shorter passwords.

I understand that my password is exceptional long, as I still was (and maybe
still am) a beginner on the encrypted mail part. But backwards compatibility
seems pretty important in the case of encrypted mails and passwords to decrypt them.

This has meanwhile been fixed in master with commit 9edcf109.
I don't see a reason tobackport it to 1.6.

I don't think it makes sense to backport it to 1.5 - it has been this way for so
long. Users of 1.5 should upgrade to 1.6.0.

And in master with commit 5f2af6c2

Agreed: Homedir should be passed to the agent. Will be changed for 2.1 and
maybe backported to 2.0.

Right, --help displays only a selection of commands. This is on purpose.
gpg --server is not ready for use and you are ready that it should not be
displayed in the help pager either.

I'll go over your list as time permits. Thanks.

damn, thats the creation date of the last userid - i was too stupid to read the
draft of hkp.
http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00#section-5.2
-> Close

The issue is that when the gpg starts the agent by itself (that is there is no
agent currently running) it does not forward the --homedir option.

And another issue is that the homedir can not be specified as relative path.
(OK, that could be accepted as security feature).

--load-extension is a dummy function. It does not do anything.