Another problem seems to be that libtool/automake does not differentiate between library dependencies needed for building the library itself and library dependencies that should be exported to users of the library. There's just mylib_la_LIBADD for specifying the internal/private library dependencies and those also end up as dependencies in the .la file. Or maybe the dependencies in the .la file are used by the original libtool only for building static libraries and it's slibtool's fault to also copy the dependencies verbatim when building a shared library.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 14 2022
I have checked where -L/usr/lib64 comes from. Ultimately, it seems to come from gpg-error-config --libs which outputs -L/usr/lib64 -lgpg-error. I have no idea why gpg-error-config --libs adds the -L/usr/lib64, but this seems very dangerous to me and was bound to cause trouble because a -L applies to everything that follows and not just to the following -l.
Aug 13 2022
You probably have to call strace with -f, so that processes started by clang are also straced.
Your observations seem to confirm that the linking picks up the old 1.17.1 version of libqgpgme instead of the newly built one. You could use strace to dispel last doubts. In any case this very much looks like a problem in slibtool.
Aug 12 2022
Hmm. There is a -L/usr/lib64 before -L../src/.libs. I guess this causes problems if there is a /usr/lib64/libqgpgme.la because this will be found before the newly built libqgpgme.la in the build directory.
revokekeyjob.moc is included by job.cpp (as many other *job.moc files). The missing symbols should be available in the built libqgpgme.so. The command line
rdlibtool: link: clang++ t-revokekey.o t-support.o -g -O2 -L../../cpp/src/.libs -lgpgmepp -L../../cpp/src/../../../src/.libs -lgpgme -L/usr/lib64 -lassuan -lgpg-error -lassuan -L../src/.libs -lqgpgme -L../src/../../cpp/src/.libs -lgpgmepp -L../src/../../cpp/src/../../../src/.libs -lgpgme -lassuan -lgpg-error -L../src/../../../src/.libs -lQt5Core -L../../../src/.libs -lgpgme -lassuan -lgpg-error -lQt5Test -lQt5Core -lstdc++ -o .libs/t-revokekey
includes -L../src/.libs -lqgpgme. So it should link against the newly built library and not against an installed library.
I have no idea why OpenKeyChain cannot decrypt TestFileB.pdf.gpg. Here is the packet list (with automatic decryption).
$ gpg --list-packets TestFileB.pdf.gpg gpg: encrypted with rsa3072 key, ID B29C3E00B6EF27FA, created 2022-08-12 "TestKey4 <TestKey4@Email>" # off=0 ctb=85 tag=1 hlen=3 plen=396 :pubkey enc packet: version 3, algo 1, keyid B29C3E00B6EF27FA data: [3071 bits] # off=399 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb :encrypted data packet: length: unknown mdc_method: 2 # off=420 ctb=a3 tag=8 hlen=1 plen=0 indeterminate :compressed packet: algo=1 # off=422 ctb=90 tag=4 hlen=2 plen=13 :onepass_sig packet: keyid BBF1585AFE6385A9 version 3, sigclass 0x00, digest 10, pubkey 1, last=1 # off=437 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb :literal data packet: mode b (62), created 1660319025, name="", raw data: unknown length
$ gpg --list-packets TestFileA.pdf.gpg gpg: encrypted with ECDH key, ID 8594A0FBC4AFAF88 gpg: public key decryption failed: No secret key gpg: decryption failed: No secret key # off=0 ctb=84 tag=1 hlen=2 plen=94 :pubkey enc packet: version 3, algo 18, keyid 8594A0FBC4AFAF88 data: [263 bits] data: [392 bits] # off=96 ctb=d4 tag=20 hlen=2 plen=0 partial new-ctb :aead encrypted packet: cipher=9 aead=2 cb=16 length: unknown
-> This still uses AEAD. It seems Werner's method to remove the AEAD feature doesn't work. At least not with gpg 2.3.7.
$ gpg --edit-key 8594A0FBC4AFAF88 Secret key is available.
Does the progress bar really say "Verschlusseln" (with u instead of ü) or this is a bug in the screen capture tool? In the pinentry dialog there are also two ü that are displayed as u.
Observations:
- TestKey1 (gpg 2.3) is an ECC-key (ed25519/cv25519) while TestKey3 (OpenKeyChain) is an RSA-key (rsa3072). I assume that OpenKeyChain supports ed25519/cv25519.
- TestKey1 (gpg 2.3) states that it supports some advanced OpenPGP features: features: 07 (= 0x04 + 0x02 + 0x01).
- TestKey3 (OpenKeyChain) states that it only supports one advanced OpenPGP feature: features: 01
Some details about TestKey3:
$ gpg --show-keys backup_2022-08-11.sec pub rsa3072/BBF1585AFE6385A9 2022-08-12 [SC] 4AFA1B0808A82E3EF941B067BBF1585AFE6385A9 uid TestKey3 <TestKey3@Email> sub rsa3072/F3E9DFE37D777AEF 2022-08-12 [E]
Some details about TestKey1_0x31B038AA:
$ gpg --show-keys --verbose TestKey1_0x31B038AA_public.asc pub ed25519/CD1E530031B038AA 2022-08-12 [SC] [expires: 2024-08-11] A438C95B6CAA724BC9F3DEB9CD1E530031B038AA uid TestKey1 <TestKey1@Email> sub cv25519/B390B84B58866C6A 2022-08-12 [E] [expires: 2024-08-11]
Aug 11 2022
Please don't yell at us!
All issues were "fixed" by getting rid of the dialog for T6115: Kleopatra: On "revoke certification" do not offer keys which did not certify that certificate.
Depending on what the user selected (key, one or more user IDs, a single certification) all certifications that the user can revoke are determined and, after confirmation, are revoked one after the other.
Aug 10 2022
Aug 9 2022
The option to flag a user ID as the primary user ID is now available in the Certificate Details dialog as button below the user ID table and as context menu entry of the user ID table.
Aug 8 2022
Should be fixed. A copy of an older version of pinentry's source code that can be built with Q4 is now included and will result in a pinentry-qt4 executable. Note that while we won't break this pinentry intentionally we won't maintain it either.
Aug 5 2022
Note to self: T6100: Kleopatra: Make revocation of certifications accessible may be obsolete when the improvements are completed because then the dialog will most likely be gone.
If the user cannot revoke any of the certifications of the selected key or user IDs, then we now inform the user about this instead of showing the dilaog.
We now propose "<fingerprint>.rev" in the last used export directory as file name. This is the same file name as for the revocation certificates that gpg automatically writes to the openpgp-revocs.d folder when a new OpenPGP key is generated.
Aug 4 2022
I have kept a backup copy of a WKDRefreshJob locally. ;-) But that's stuff for a different task.
Looks good. After entering a wrong passphrase three times Kleopatra now reports
Moving the key to the card failed: Bad passphrase
gpg was waiting for the passphrase for the signing key to be provided via stdin.
See T5903: Kleopatra: Add refresh button in certificatedetails for the corresponding Kleopatra task. Kleopatra now uses the good old ReceiveKeysJob for doing a key refresh from the configured key server. The RefreshOpenPGPKeysJob has been removed.
For an OpenPGP key, Update now performs a simple "retrieve key" operation for the existing key, i.e. it refreshes the key with the public key found on the configured key server.
Aug 3 2022
Did you restart Kleopatra after enabling the high contrast mode? I have implemented that Kleopatra doesn't change/set any background or foreground colors if high contrast mode is detected. Maybe the detection (in SystemInfo::isHighContrastModeActive) doesn't work.
All issues were addressed.
Okay. I do a KeyListJob with key list mode GpgME::LocateExternal which does the equivalent of --locate-external-keys and that depends on the auto-key-locate mechanisms which could include keyserver and other mechanisms besides WKD.
The lookup by email address is supposed to be done via WKD. Obviously, a lookup by fingerprint wouldn't work. And yes, obviously this may import additional key via WKD.