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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 27 2014
Jan 24 2014
No we won't do this. IIIRC, there is another rejected bug report and we also
had a discussion at the ML.
Jan 17 2014
Dec 10 2013
Libgcrypt 1.6 will be released this year.
Nov 29 2013
Oct 25 2013
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...
Oct 24 2013
The secret keys are stored as separate files below ~/,gnupg/private-keys-v1.d/ -
gpgsm uses this method for more than a decade.
Oct 23 2013
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.
Oct 7 2013
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.
Oct 5 2013
While it is provided, please make it work. The patch is trivial.
Oct 4 2013
Did you notice the
the scripts print sicne version 2.0.13 ;-)
Oct 1 2013
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.
May 22 2013
May 21 2013
Thanks for your answer, I'll do that then.
Best regards
Loïc Gomez
May 17 2013
May 1 2013
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.
Apr 22 2013
Mar 19 2013
Mar 18 2013
1.6 (current master) now has a feature to switch to a pure /dev/random based RNG.
Feb 22 2013
Do not use an outdated version of GnuPG.
Jan 8 2013
Dec 20 2012
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.
Dec 15 2012
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.
Nov 8 2012
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.
Sep 26 2012
It is already available in the latest 2.1-beta.
That is not possible for two reasons:
- For v3 keys the fingerprint is different from the keyID.
- We often have only the keyID but not the fingerprint available.
Sep 17 2012
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".
Aug 9 2012
See my comments for T1406. It is clearly a clang bug.
Aug 8 2012
Jul 18 2012
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.
Jan 3 2012
Oct 11 2011
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!
Jul 1 2011
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.
May 16 2011
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.
Apr 29 2011
I've now switched from gcc4.3 to gcc4.4, and this warning is no longer emitted.
Apr 27 2011
We allwo only algorithms which are implemented. IDEA is not implemented because
it is patented. MD5 is implemented but too weak to be used. We won't allow that.