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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 8 2021
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.
Sep 7 2021
I see.
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)
Sep 6 2021
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 created an experimental branch:
https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Fnew-pk-api/
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.
Sep 5 2021
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
Sep 4 2021
This works for me:
Sep 3 2021
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.
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.
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.
Sep 1 2021
Based on GCC bugzilla, affected released GCC versions are 11.1 and 11.2.
(ab | ba) >= 0 is used to make optimization analysis for compiler more difficult. I see that with (ab | ba) == 0, it would be much easier for compiler to conclude than loop could exit early as soon as first a[i] != b[i] is seen.