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.

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.

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

Libgcrypt 1.6 will be released this year.

gpgsm is the S/MIME cousin of gpg.
No need for that. The files are of course encrypted.

Sorry for being ignorant, but I don't even know what gpgsm is... ;-)

I'm just using the "classical" gpg since it came into life (being a PGP user for
more than 20 years now)...

But since gpgsm seems to use a separate directory for the private keys it's fine
for me as well -- I will then mount that directory as an encrypted one...

The secret keys are stored as separate files below ~/,gnupg/private-keys-v1.d/ -
gpgsm uses this method for more than a decade.

Does that mean there will only be a single keyring in the future? So that I can
not lock-away my secret key(s) while I don't need them?

Nope; won't be done. We had this in the past and people enabled it and later
complained about disk full stati. And yes, it exposes confidential info.

2.1 will not anymore use a secring and thus this problem will soon vanish.
Fixing this may introduce other bugs, thus we better don't do anything here.

Based on that, you should remove all code from script and replace it with a
message instructing to use the other tool. I do not understand how providing
non-workable code has any value.

I do not want to reopen this... but it is odd. Feel free to ignore.

Thanks!

No. The script has only not removed to not break existsing packaging systems
and to notify the user that a better tool is available.

While it is provided, please make it work. The patch is trivial.

Did you notice the

the scripts print sicne version 2.0.13 ;-)

Merging of secret keys has never been not supported. GnuPG 2.1 has a
architecture redesign which supports secret key merging. There won't be any
backport.

Thanks for your answer, I'll do that then.

Best regards

Loïc Gomez

Given that recent versions of GnupG support IDEA and won't emit such a status
line anymore, I do not think it is justified to fix this for old gpg versions.

1.6 (current master) now has a feature to switch to a pure /dev/random based RNG.

Do not use an outdated version of GnuPG.

See the Topics field above: wontfix.
The feature request has been rejected. If you still want to pursuit it, please
start a discussion at gnupg-devel and don't contine here at the BTS.

Not ure to understand you comment...
Have you added support for XDG basedir spec?

Add more complexity to the already complex configuration.

Please notice that backward compatibility can be preserved by continue to use
$HOME/.gnupg if it exits but using/creating XDG dirs when it is not exit.

Fixed in git for gnupg 1.4.13, Libgcrypt 1.5.1 and Libgcrypt 1.6.0.

The reason why I was not able to replicate this bug was that
I didn't use -std=c99 with gcc >= 4.3.

It is already available in the latest 2.1-beta.

That is not possible for two reasons:

1. For v3 keys the fingerprint is different from the keyID.
2. We often have only the keyID but not the fingerprint available.

Ok I did some more research on this topic and it appears ECC is the fix for RSA
additional key sizes. Do you have any idea when ECC will be implemented into
this gem? This draft appears to be expired though so its unknown to me if there
are plans to get this implemented into the default software without requiring a
patch.

Draft: https://tools.ietf.org/html/draft-jivsov-openpgp-ecc-11

Once again thanks for the feedback. I tried to search but I kept getting errors
so I apologize if this was previously addressed.

No.

Please read all the long threads on gnupg-users to learn why this is not a good
idea. You may also want to read Ross Anderson's "Security Engineering".

See my comments for T1406. It is clearly a clang bug.

The gpgme-config scripts goes along with the gpgme.m4 code. A .pc file won't be
able to do what we can do with this combination.

Please disregard my stupid comments about GPA. I was on the wrong track.

We use what the system tells us. See jnlib/utf8conv.c:set_native_charset . An
alias for CP866 might be missing. We don't switch the console charset but use
libiconv to translate between charsets.

I wrote a small test program for .Net to see what is console charset:

But why is it unreadable? I see Cyrillic letters (gpgconsole.jpg) but this is
not Russian text!

Wint 2.1 the protect-tools has been dropped. Thus we won't fix it in 2.0.

It seems this is not important enough to implement an extra filter for this case.

Please use a wrapper for this. The problem with an --language option is how
should we display messages pertaining to option parsing if we don't have the
languages already set. This might lead to a mixup of languages which for sure
will yeild in complains by other users.

I've now switched from gcc4.3 to gcc4.4, and this warning is no longer emitted.