Printing a note as we do in --edit-key is a good idea.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 14 2022
Apr 9 2022
The reason for this is probably that we expect that several UIDs are added and running a check-trustdb for eachleads to some extra waiting time.
Apr 8 2022
Apr 5 2022
(Werner just told me that I was mistaken and he needs to take a look. There was a mixup because of the 2018 CVE number.)
Sorry, that was a misunderstanding. My fault.
Apr 4 2022
In fact, decent 2.2 versions (>=2.2.21) have the ability to decrypt AEAD packets - this has been implemented exactly for the case that some things get wrong at the user site. But we can't change old versions - we are not the Sirius Computer Corporation. I close this ticket because we can can't do anything if you are not able/willing to update to the latest version of the respective branch. Sorry.
Apr 2 2022
@werner
The setpref S9 S8 S7 S2 H10 H9 H8 H11 H2 Z2 Z3 Z1 worked!
Apr 1 2022
S9, etc. are short-hand IDs, for the cipher algorithms, digest algorithms, etc. Use showpref instead of pref to get the preference list in human-readable form (AES256, SHA512, etc.) instead of in expert form (cryptic IDs).
Hi @werner
I had missed your earlier post quoted below on using setperf.
Create the keys with gpg 2.2. I'm not aware of such documentation apart from the manual page of GnuPG. And, as I tried to explain, this situation isn't really different from any other software. If you create a document with the newest version of LibreOffice then you cannot expect it to look exactly the same with an older version of LibreOffice. It's your responsibility not to use new features of the new LibreOffice if you still need to use an older version on another machine.
@ikloecker Thanks for the clarification (appreciated).
Backward compatibility means that newer versions work with data created with older versions of a program. What you are asking for is forward compatibility, i.e. you want older versions of a program to work with data created with newer versions of a program. In the extreme that would mean that gpg must not use modern encryption algorithms because old versions of gpg cannot deal with them. It should be obvious that this doesn't make any sense.
@ikloecker thanks for your reply.
Mar 31 2022
Not in the way it is used by gpg. See T5880
Mar 30 2022
Not in the way it is used by gpg. See T5880
Mar 28 2022
Good idea. Thanks. Goes onto 2.3 and 2.2
In T5886#156407, @TonyBarganski wrote:
- As things stand right now, someone with a Public key created on gpg version 2.3 on a macOS cannot privately communicate with someone using a Linux server, news group or Linux Desktop.
Use a gpg 2.3 version:
Mar 25 2022
Hi Werner
.
Firstly, let me say how much I appreciate the work you and others do at OpenPG.org! Really.
- No we can't because current GnuPG 2.2 versions are able to decrypt such AEAD data.
- So, firstly, can we get an error message that states something to that effect AND can also be displayed by Mutt?
Packet 20 is the new AEAD packet which GnuPG 2.3 can generate and does generate if all recipients have new keys generated with such a versions. However, the version of gpg you use now does not support AEAD and thus fails.
Mar 21 2022
Using an armor header would allow for this. But well, this blows up the data and frankly, I fear that it can lead to unexpected side effects. Better to use a respective file name or MIME header.
Adding
GPG_TTY=$(tty) export GPG_TTY
makes this working so thank you for the pointer.
Mar 18 2022
Is your GPG_TTY set so that pinentry can find the right tty?
the -v does not show more useful info on the gpg side:
# gpg2 --quick-gen-key admin About to create a key for: "admin"
Please run with option -v to see what's wrong with pinentry.
Mar 17 2022
Mar 16 2022
Mar 15 2022
Mar 12 2022
Mar 7 2022
I went through my test files and found that --enarmor on zero length input file did no longer work. I made separate patch to fix that issue, which then also needs another approach for handling compress issue noticed earlier:
Ack from me for new 0005 and 0006.
Mar 6 2022
Mar 3 2022
Mar 2 2022
Mar 1 2022
Great. No problem for me.
Feb 27 2022
Feb 25 2022
I used "1<<30" by example of existing code in g10/free-packet.c, which is another place where iobuf_read is reading to NULL.
Patches look good for me.
Please go ahead.
Feb 24 2022
Feb 23 2022
Feb 21 2022
Feel free to ask me by PM if you run into problems (wk at gnupg.org). Two of my colleagues are Vim users and thus have an interest in a well working plugin :-). Thanks.
Feb 17 2022
I have tested it. When I try it with public keyserver it has of course problematic results when vandalized keys like werners are hit but its great that even if I abort at that point I nicely see the results of the other imports.
Feb 16 2022
Feb 11 2022
Feb 10 2022
Feb 9 2022
Optional automatic retrieval after import of new OpenPGP keys is now also possible.
Feb 7 2022
Yes, it would be convenient to use the same $GNUPGHOME in Git Bash (using /usr/bin/gpg) as in PowerShell / Cmd (using gpg.exe in %PATH%)
Feb 4 2022
Manual retrieval of missing certification keys is now possible from the Certifications dialog.
Jan 31 2022
As this hinders the trusted-introducer setup in Keyserver centric deployments we should treat this with high priority.
Jan 28 2022
Jan 18 2022
vitusb: We had this discussion on cryptography@ years ago. No need to start it again - or well, try it over there. This is a bug tracker and not a discussion forum.
These curves are not the default in the compliance mode "gnupg" only if you explicitly switch to the BSI defined "VS-NfD" mode they become default.
Jan 17 2022
In T5783#153879, @werner wrote:Sending a private key with just the local protection is not a good idea.
In T5784#153872, @werner wrote:Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.
Sending a private key with just the local protection is not a good idea. It is better to export the key and then send it in an encrypted mail - for example in symmetric mode with a strong password.
Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.
Jan 16 2022
Jan 15 2022
Jan 14 2022
Jan 11 2022
I found this post when I was searching everywhere for a solution, and I was delighted. I've recently been trying to upload GpgFrontned in the Apple Store vs Microsoft and I'm having some trouble.
Jan 10 2022
Dec 23 2021
The odds for this case are infinitesimal so this should not have high priority. I consider this only a code-is-as-specified thing.
Dec 22 2021
Dec 20 2021
We can even remove the hexfingerrprint call. Will go into 2.3.4. Thanks.
So, this is the patch. Note that this is for master.
diff --git a/g10/keygen.c b/g10/keygen.c index 7f15027a2..a452ab6d6 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -5619,7 +5619,7 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, pk = find_kbnode (pub_root, PKT_PUBLIC_KEY)->pkt->pkt.public_key;
The use of register_trusted_key in do_generate_keypair was a dirty hack utilizing a bug in --trusted-key ; it would be better to set the key as ultimately trusted.
I think that the change for T5685 introduced the issue.
Dec 19 2021
Okay, sorry. In the first two cases (encryption), GnuPG 2.2.33 generates
[GNUPG:] INV_RECP 10 F3C987C36C5C6343C9A5D5A1A3F494F6028E4866 [GNUPG:] FAILURE encrypt 53 gpg: [stdin]: encryption failed: Unusable public key
and exits with error code 2, whereas 2.2.32 doesn't display these messages and exits with return code 0.
Please be so kind and describe the regressions you see. 3 log files from your software are not very helpful.