Yes, we read up to the first LF. This has been the traditional way of PGP2 and is still used by mail programs like Mutt.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 3 2021
Sep 2 2021
I'm guessing gpg in Unix has stripped the \n if present? I don't have access to a real Unix system at the moment.
I see that problem but gpg has traditionally not interpreted the passphrase in any way. Right, for Windows we could strip the CR but I fear that this might break other users scripts/passphrases. However there should be a warning in the manual.
Aug 31 2021
gpg verifies the content of the file and not its meta data (file name). Thus an empty file is identical to a non-existing file. The OpenPGP protocol does not allow to distinguish between a detached signature and an embedded signature if you sign an empty file.
Aug 29 2021
Nah, I think I laid out all my arguments by now. I don't have more to add, so I'll just let it be.
Thanks for helping out @werner.
Not at all. But 2.1 was such a large change that users really should have read the announcement and think about their use case. We have exensivly communicated the changes and can expect that users test their new installation. IF you have further comments, please use the mailing list.
You can write your own pinentry script instead of the loopback thing. The use the envvar PINENTRY-USER_DATA to communicate with the pinentry.
I'm still sad that you don't acknowledge the problem I am describing. It seems that you are writing your software for the kind of user who reads all your documentation first. That kind of user does not exist.
Aug 28 2021
The option has been removed form the repo more than 11 years ago and the gnupg with this changes (2.1.0) was released 7 years ago including an extensive writeup on all the major changes including notices that the secret keys will be converted and moved.
Aug 26 2021
Aug 25 2021
Okay, I close this as a keyserver infrastructure problem. Feel free tore-open if you get other infos.
Fixed in 2.3.2.
Aug 24 2021
Aug 13 2021
At first I've had simply tried to give multiple --symmetric options (which of course didn't work).
I have no clear idea on how to style the UI for this feature. Technically it is simple but we need top query several passphrases. loopback mode with a list of passphrases might be easiest way to do that.
Aug 9 2021
Yeah, that sounds good to me.
Aug 8 2021
In T5551#148510, @werner wrote:I would prefer to see a fix/hack in pinentry-qt instead.
Aug 6 2021
I see. Thanks!
To minimize the risk of regressions.
Not to be bothersome, but why? DISPLAY seems like the universal method of selecting a display to put things on, where a lot of applications don't support --display or equivalent, especially now there's no equivalent for wayland. It's especially confusing to me when the keep-display option will pass DISPLAY instead of --display. This would also prevent other such scenarios with 3rd party qt/gtk plugins or alternative pinentry implementations.
I would prefer to see a fix/hack in pinentry-qt instead.
Proposed patch:
--- gnupg-2.2.27.orig/agent/call-pinentry.c +++ gnupg-2.2.27/agent/call-pinentry.c @@ -202,13 +202,14 @@
Aug 3 2021
Aug 2 2021
I propose the following patch to inform the user about the obsolete --secret-keyring option. The same is done for many other obsolete options.
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.