This is a hard to solve problem in the NSIS installer: If you accidently started more than one installer they may both register files for update at the next restart. Now after the restart the file which is to be renamed does not anymore exist and thus a component or even library is not available. In this case it is GpgEX, the explorer plugin.
Wed, Sep 8
In the editor you find a cloud symbol with an arrow to upload a file. Use this and and the file id will be pasted at the cursos, like here
Apologies for my (newbie) comment on this bug reporting system. Since I have a screen shot bitmap better showing error I described, could anyone tell me how to attach to this bug ?
Finishing development for now.
Please talk to the KDE folks who develop Craft. We do not support building anything with Craft. Check out gpg4win (https://dev.gnupg.org/source/gpg4win/) to see how we build our products on Windows.
Which product do you refer to? Kleopatra? gpg4win? Something else?
Which operating system are you using? Windows? Linux? Something else?
The major problem I see is that an implementation needs to add more crypto primitives to support ths curve. And we can expect that 448 will eventually get in widespread use. We already have all primitives but would inhibit the creation of minimal implementations.
Tue, Sep 7
BTW, the reason of the name "pkey" is that because gcry_pk_ctl is already occupied.
It will be changed, if needed.
Today, I pushed an example for RSA-PSS.
I have approved the commit in KDE's GitLab. For details see https://invent.kde.org/pim/kleopatra/-/merge_requests/8
Fixed in 2.3 and 2.2
The task is T5577 (which I accidently closed during triage)
(I closed this by accident)
Mon, Sep 6
This commit breaks decryption of symmetrically encrypted data. gpg-agent segfaults after one has entered the passphrase in pinentry.
I added couple of minor comments. I hope they went into somewhere.
looks good to me. Tested now with master 47e425e07995454573e28c13c08229d2f8a75642 and all tests pass for me in and out of FIPS mode as well as in the "soft" one.
I was a bit confused about AESWRAP. Please forget I wrote above. (We already have support of larger keysize ECC, NIST P-521, for example.)
I created an experimental branch:
- For OpenPGP format of Curve448, it is ok for me to change the format, but I found more serious issue about use of AESWRAP.
- Considering about new public key API for libgcrypt, I thought that calling encrypt/decrypt would be confusing for ECDH. (because it's actually doing ECDH computation, which is used for KDF in later stage, and then it's AESWRAP which does encryption/decryption with session key in an application)
- Then, I found that: for use of AESWRAP for ECC with larger keysize (like Curve 448), while it is expected to use larger block size (for Curve 448, use of 256-bit) naturally, but current experimental implementation in gnupg2.3 does AESWRAP with 128-bit block size.
- That's because of the situation, AESWRAP in libgcrypt is only for 128-bit block size currently.
- Continue T5576: New set of API for public key cryptography
- ???libgcrypt: AESWRAP with different block/key size???
Let's meet today at https://meeting.iacd.net use g10code as user
I think this issue is solved. For systemd, I need to run this as --supervised option not the --daemon option. The --daemon option has bug.
Sun, Sep 5
Nevermind, I found the appropriate link above, thanks again.
Thanks for noticing me but I can't access your git repository at https://dev.gnupg.org/source/gnupg.git and the github mirror at https://github.com/gpg/gpgme is not up to date. Do you have an other mirror?
You could use --disable-keyboxd which should fix this. However, there will eventually be no more way to build w/o Sqlite and thus I would suggest not to allow disabling of sqlite.
Thanks. This has already been fixed in July with rM4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e
Sat, Sep 4
This works for me:
Fri, Sep 3
I think the behavior makes perfect sense for Unix but the default delimiter for .txt in Windows is \r\n.
The OP wants to do symmetric encryption. This isn't about the passphrase that protects a key.
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.
Thu, Sep 2
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.
The actual problem is not that --list-packets produces weird output, but that --decrypt fails with
gpg: [don't know]: invalid packet (ctb=4f) [GNUPG:] NODATA 3
causing confusing errors in Kleopatra.