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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 5 2021
Thanks. This has already been fixed in July with rM4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e
Sep 3 2021
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 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 30 2021
Aihhh, my fault. seems that a new version it not too far away.
Aug 29 2021
We will look into it but nevertheless I have to remark that this this portable thing is dangerous to use and you should avoid it.
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.
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.
I wonder about the spelling errors. For particular
Please show us the output of
Aug 27 2021
Aug 26 2021
Is there another way to to detect your card (I assume a Javacard) without relying on the openpgp card application vendor-id like we do it with the Yubikey? I want to avoid a possible early but expensive AID selection just to get the vendor-id.
It is quite likeley that things don't work on a non-released Windows version. We have not tested with the released version but some of us already tried Windows-11 and the gog4win development versions do work. Please wait for the next Gpg4win version or an update of the Windows-11 preview.
Will only be fixed for 2.3 and that has already been released.
I tried applied the bulk of the patch to 2.2 but w/o reading the key creation time from the card. We don't have the supporting code for latter in 2.2. However this does not make sense. Users should switch to 2.3 if they needs this feature.
We need a more detailed bug report to evaluate your problem. Please tell us your Windows version, any special software installed on the system (if any), a step by step description how to reproduce the bug, and any other information which can help us.
Aug 25 2021
Okay, I close this as a keyserver infrastructure problem. Feel free tore-open if you get other infos.
Thanks fro the report. Unfortunately I am not able to reproduce this on our systems. It might be an issue with other software on your system or a problem in our code. This is the first such report and as long as we don't get reports from other users, we can't do much for you. Please try installing on a different system or if you can provide more information feel free to re-open this bug report.
Will do.
Aug 24 2021
Aug 23 2021
I think the last user of random-fips was removed with rCed57fed6de1465e02ec5e3bc0affeabdd35e2eb7
Yes, it makes sense to remove it.
Oh yes, I was blind.
A cursory look doesn't show me where list->result is set to something else than -1. Can you give me a hint?
Aug 22 2021
Fallout from the fact that the @cbiedl left us and had an internal non-tagged ticket left open (T5456)