Oh ok!
Thanks
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 4 2022
This change is wrong. The correct fix is rM31423945d214: qt: Fix filename of cmake config files for w32.
Jun 17 2022
Jun 14 2022
As Werner wrote, this is already possible. The next time please consult the extensive documentation of gpgme before opening a ticket.
Jun 13 2022
Hmm, why not use:
gpgme_op_sign (ctx, in, out GPGME_SIG_MODE_CLEAR)
Jun 10 2022
Fixed. Thanks for the report.
Yeah, seems to be related to daylight saving. Running
TZ='America/Adak' GPGME_DEBUG=3 TESTS="initial.test t-various" make -e check-TESTS
results in
FAIL! : TestVarious::testSignKeyWithExpiration() Compared values are not the same Actual (expirationDate) : 2106/02/04 Expected (QDate(2106, 2, 5)): 2106/02/05 Loc: [/home/ingo/dev/g10/src/gpgme/lang/qt/tests/t-various.cpp(342)]
because the code adds 30555 days to the current time (2022-06-10-00:xx:xx+UTC-9) which gives us 2106-02-04-23:xx:xx+UTC-10.
I couldn't reproduce the one-off problem of the original report, but running the test with time zone UTC-11
TZ='Pacific/Pago_Pago' GPGME_DEBUG=3 TESTS="initial.test t-various" make -e check-TESTS
resulted in
FAIL! : TestVarious::testSignKeyWithExpiration() Compared values are not the same Actual (expirationDate) : 2022/06/09 Expected (QDate(2106, 2, 6)): 2106/02/06 Loc: [/home/ingo/dev/g10/src/gpgme/lang/qt/tests/t-various.cpp(342)]
because adding 30557d (number of days in UTC-11 until 2106-02-06) to the current time resulted in a u32-overflow. I'll change the maximal expiration date to 2106-02-05 to avoid the overflow.
Jun 9 2022
May 24 2022
Having written the code and the test I'm with dkg here. The code takes the expiration date, calculates the number of days from today and tells gpg to set the expiration to <number of days>d. The idea of the aforementioned is that it should work for any timezone. Maybe this assumption is wrong.
May 23 2022
I see the patch which does look like it will guarantee that the test suite succeeds. But does it solve the underlying problem, though? I worry that it might just paper over a more subtle problem.
Thanks. The solution should thus be easy.
May 21 2022
May 13 2022
We have a workaround by using a recent version of gpgtar directly. Thus lowering priority.
May 6 2022
No sure, you could also consider the is_cardkey flag to mean that a secret key might be available. FWIW, GPA sets it internal secret key flag based on the type of listing done; thus I see no problem if you want to change the behaviour.
May 5 2022
Apr 29 2022
Tested
Apr 27 2022
Apr 25 2022
Works together with the changes for T5939: Kleopatra: Better error for wrong password in symmetric decryption. Tested with symmetric encrypted file and with symmetric+pk encrypted file.
In this case it works, because the error messages are not translatable.
In T5939#157259, @werner wrote:You should not use log messages because they are subject to change and they are translated. Let us return an ERROR status instead.
Apr 24 2022
You should not use log messages because they are subject to change and they are translated. Let us return an ERROR status instead.
Apr 22 2022
I have added the check for a possibly wrong symmetric password to QGpgMEDecryptVerifyJob because it relies on logging messages emitted by gpg which are not part of gpg's status API.
Apr 20 2022
Apr 14 2022
Works for Kleopatra.
Mar 30 2022
Mar 28 2022
Summary of abidiff for libgpgmepp:
Functions changes summary: 6 Removed (20 filtered out), 0 Changed, 0 Added functions Variables changes summary: 2 Removed, 0 Changed, 0 Added variables Function symbols changes summary: 0 Removed, 0 Added function symbol not referenced by debug info Variable symbols changes summary: 12 Removed, 0 Added variable symbols not referenced by debug info
Mar 21 2022
Mar 19 2022
Mar 16 2022
Mar 7 2022
Should be fixed.
Mar 6 2022
The patch for T5834 (https://dev.gnupg.org/rMad3aabdd8a64156c7e3a75d695ae1ab2c4bec841) was already applied to the build of GPGME 1.17.0 for Focal, as I did browse the list of latest GPGME bugs first before reporting this bug. Attempting to build with the latest GPGME 1.17.1 (with the included ABI patch) results in exactly the same FTBFS for i386 only, so this does appear to be a distinct issue not related to that of ABI backwards compatibility.
Please see T5834 which is fixed in 1.17.1
Note the ABI bug the Qt version of 1.17.0 which is fixed with 1.17.1 (T5872)
Feb 17 2022
Feb 14 2022
Found it: I did not initialize gpgme_op_interact's last parameter out with gpgme_data_new. The error is now gone.
Since you are using C++, I suggest that you have a look at GpgSetOwnerTrustEditInteractor in the C++ bindings of gpgme. Have a look at QGpgMEChangeOwnerTrustJob in the Qt bindings of gpgme to see how it's used even if you do not want to use Qt.
Feb 13 2022
Feb 10 2022
Feb 7 2022
Feb 2 2022
Jan 31 2022
Jan 24 2022
Yes, kleo always maps '+' -> ' '
Jan 21 2022
This looks like a missing escaping issue in the sender (scdaemon?) or an unwanted unescaping issue in the receiver of the string (which uses Kleo::hexdecode()).
Jan 20 2022
Thanks
gpgme_key_t is a different kind of object than a gpgme_foo_result_t and thus has different properties.
Jan 12 2022
Dec 17 2021
Thanks!
I will study it soon.
Dec 16 2021
Use the source! GnuPG is free software.
Dec 15 2021
I tested the change of last_update after importing a same key with different content, but found that there is still no change.
Dec 14 2021
On import. Please use gnupg-devel mailing list for further API questions. This is a bug tracker and not a help forum.
Dec 13 2021
Nice. The way with KS_GET and assuan is much better then I thought about using a temporary home and a --locate-key