I propose the following patch to inform the user about the obsolete --secret-keyring option. The same is done for many other obsolete options.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 3 2021
Aug 2 2021
Aug 1 2021
This is very saddening and alarming from a respected member of the community whose opinion matters.
You should have read the release notes of 2.1 (first point). We can't keep a bug open because you had a wrong understanding of GnuPG properties. Sorry.
Jul 31 2021
Jul 26 2021
Sorry, I don't understand what you are trying to say, so let me give you some more detail.
Everything in ~/.gnupg is and has always been private to gnupg unless explicitly stated otherwise.
Jul 25 2021
For many years I was convinced that my secret keys are stored in an encrypted folder. The .keyring file was there, everything looked correct...
Jul 15 2021
Forgot to mention one thing: after changing my user folder directory I lost all my Outlook contacts. I was able to recover them... make sure you have a backup before attempting this!
Jul 12 2021
I just had the same issue as hurui200320. My user name contains a "ç" and Kleopatra did not start. The Windows event logger reported a crash in libstdc++-6.dll. This was with gpg4win-3.1.16. Installing gnupg 2.3.1 did not change anything.
Jul 6 2021
In agent_write_private_key of agent/findkey.c, when file is available, it returns GPG_ERR_EEXIST error. Thus, private (stub) key will be kept.
Jul 5 2021
Jun 29 2021
Do I correctly understand that issue will be resolved on GnuPG side by tweaking key bits before private-key import/and/or/operations?
Jun 25 2021
We should not support a different OID or representation of 22519 which will only lead to incompatibilities and trouble existing users. 25519 is in too widespread use than to allow for any changes.
Jun 24 2021
Thanks werner. That helps us to know that such test failure is not a deep issue that would push us to not deliver this version of gnupg on AIX.
Jun 23 2021
Jun 22 2021
With the next release you will get only a warning:
gnupg-2.2/common/t-sexputil.c:467: test 0 failed: Unknown elliptic curve - ignored This is likely due to a patched version of Libgcrypt with removed support for Brainpool curves
Jun 21 2021
The sks pool is now officially gone.
Sorry for the expired certificate.
Fix: "I Know so few about gnupg, thus I'm not sure I COULD add test cases, probably not. "
Hi,
The site now shows: "NET::ERR_CERT_DATE_INVALID" and I have a limited access to the web page.
Thanks for you explanation. However, I now so few about gnupg, thus I'm not sure I cannot add test cases, probably not. I'll see later if we have to provide on AIX a behavior different than the one of RedHat. Meanwhile, about your last proposal, yes it would be very useful to detect the case, print a warning, and skip the test. That would be helpful. Moreover, if the test deals with smartcards, we do not have on AIX, thus this test is very probably not useful in our environment.
The thing is that I added a test for a new function which uses standard curves of Libgcrypt. But here we are again at the RedHat mess: They support the NIST curves but they removed support for Brainpool curves. Both are very similiar curves just different parameters. Brainpool is just in Europe out of fear that the NIST curves are rigged by the the NSA. Now, why RedHat removed Brainpool is probably just a legal dept thing who didn't have a clue. The tin foil hats probably see a different reason.
- a patch change within scd/apdu.c dealing with a call of: pcsc_connect() since code has changed between the 2 versions: may this be the cause of the failure? (Edited: hummm this patch seems no more required. And I have the same failure without it).
Hi Werner,
Supported curves should be listed by
gpg --list-config --with-colons curve
I am not sure about Fedora, but RedHat used to remove ECC support from Libgcrypt; GnuPG requires these curves. As long as you don't use ECC you things will work despite of this failed test. The test is new to check and does not anticipate a broken Libgcrypt.
Jun 17 2021
Thank you.
Jun 14 2021
Hi, I updated the whole file, PLZ review. https://dev.gnupg.org/D533
Jun 13 2021
Thank you for your suggestion and making a patch.
Sorry, I think, it is more official to update from 把密钥导出到一个公钥服务器上 to 将密钥导出到一个公钥服务器上 in the Chinese doc scenario. 😄😄😄😄
Jun 11 2021
Thank you Werner for fixing this! We just came across the group permission issue in a multi-user environment and all we had to do was to upgrade to gnupg >=2.2.24.
Jun 10 2021
Pushed the change.
Considering the history of the translation, I concluded that it should be:
把密钥导出到一个公钥服务器上
(the typo was G-A where B-A was expected.)
@guzhongren
This is not GitHub, so, if you want, you need to learn how to submit your change in the form of patch, by using git.
Jun 9 2021
Clone and checkout the branch as usual with Git. There is no web editor etc like you might know from github. For your request we need to wait for someone to check your request.
Now also fixed for 2.2.28
Better don't backport this.
Fixed.
I'm not sure if it's worth backporting this to 2.2.
I encountered this bug last year, but I realized that it's hard to make a reproducible case.
Jun 7 2021
In your log, it says:
usb_claim_interface failed: -3
Sorry, I was wrong.
Jun 4 2021
I need to see how we can pass the check permission notice up to gpg. This is a too common problem and thus serves some special treatment.
GPG Version :
In T5442#146871, @gniibe wrote:I see your situation
Could you please help me to analyze what's going on?
Please add following lines to your scdaemon.conf to see CCID driver's debug output:debug-ccid-driver verbose verbose verboseAnd share the debug output.
Ah, I think that your problem was fixed in rG53bdc6288f9b: scd: Recover the partial match for PORTSTR for PC/SC. (to be 2.3.2).
I see your situation
In T5442#146869, @gniibe wrote:If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?
If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?
Jun 2 2021
Hi Werner, I need this for a potentional customer. And generally I need this in config, too. because in support we have to send customers configuration files which they do not need to edit and variables are important because of file system permissions. But most immedialtely I need this for homedir registry.
jitterentropy is also used in Linux kernel, and some people use clang to build it these days. So, I checked the kernel's one. It is simply compiled -O0 by Makefile, and there's no pragma line now (as of v5.13).
Jun 1 2021
I don't think that it is a good idea to silence this warning. The pragma is esssential for proper random numbers and if clang hijacks a GCC's name space but implements something different it is better to have a warning than to fall into the pit full of dragons.
In T5369#144864, @jukivili wrote:That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).
May 27 2021
I test on ppc64 machine (POWER9, big endian).
May 24 2021
May 21 2021
Could make --multifile work on windows 10, documenting the workaround here.
May 20 2021
This is another test case for GNU C library's strncmp:
This is the minimized test case.
May 19 2021
Thanks for the well written report. We had another already, and thus I merged it into T5415.
May 12 2021
Frankly, I am pretty sure that the new base64 encoding of the fingerprint leads to less diligent comparison of the fingerprint by the user. I don't understand why they did not used a truncated hex output or zBase32 .
May 11 2021
May 7 2021
Ah, great. Thanks!
May 6 2021
May 3 2021
Thank you for taking time to look into that. There are couple of issues in the CAcert bug tracker talking about the same issue but if, (I see right), the certs still miss the usage flags:
RFC-5280 states in 4.2.1.3 for Key Usage:
Any chance looking into this @werner?
Apr 27 2021
The curve is not defined to be used for ECDH (encryption); in fact it should in general only be used with the EdDSA
algorithm. You need to use "Key-Type: eddsa". Note that the EdDSA signing algorithm is different than the commonly used ECDSA signing algorithm.
Thanks for the quick response Werner. I knew I could use it with quick-gen-key and I’ve updated my config file to have it as default.
But, just for my understanding, is there a reason ed25519 cannot be used with full-gen-key and gen-key in batch mode?
You can't use ecdh with ed25519.
Apr 26 2021
Update:
It looks like OpenSSH version 8 now supports ssh-agent's handling REQUEST_IDENTITIES.
Apr 20 2021
it's in 2.3.
Apr 16 2021
This has been fixed in version 2.2.16.
Apr 15 2021
gpg4win 3.1 has no full Unicode support. You may try to install the new GnuPG 2.3 version on top of gpg4win to fix this problem or wait until we have releases gpg4win 4 which will come with GnuPG 2.3.
Apr 13 2021
Done in 2.3.0.
Done in 2.3.0.