Closed kaie closed 3 years ago
Sounds like we should bump the priority of https://github.com/rnpgp/rnp/issues/1147 up
@dewyatt Agree. I'll handle these, it should not be hard to parse this custom s2k. The only question is whether rnp will be okay with secret key without secret data.
It's not yet fully working as expected.
I can import the subkeys. (I use a temp FFI handle.)
For the primary key, rnp_key_have_secret returns true. Shouldn't it return false?
Calling rnp_key_unprotect returns RNP_ERROR_BAD_PASSWORD, that might be ideal either, I'd rather expect something like RNP_ERROR_KEY_NOT_FOUND.
On the console I see [decrypt_secret_key() /home/user/moz/comm-esr78/mozilla/comm/third_party/rnp/src/librepgp/stream-key.cpp:1325] No secret key data
@kaie Yeah, looks like we should also provide some algorithm to check whether secret key data is available, and update code for default key selection during signing (so in this case signing subkey will be used).
All underlying code based on bool returns, so that's why RNP_ERROR_BAD_PASSWORD
default assumption is made.
Needs some time to think how to correctly update this, without breaking the other logic.
Btw, why do you need to use rnp_key_unprotect()
instead of rnp_key_unlock()
? First one is needed when you want to write raw secret key somewhere. To use secret key for signing/decryption is better to call rnp_key_unlock()/rnp_key_lock()
once it is requested.
Btw, why do you need to use
rnp_key_unprotect()
instead ofrnp_key_unlock()
? First one is needed when you want to write raw secret key somewhere. To use secret key for signing/decryption is better to callrnp_key_unlock()/rnp_key_lock()
once it is requested.
I currently use the following strategy for importing secret keys:
@kaie Could please check the following additions to the FFI API: https://github.com/rnpgp/rnp/pull/1248/files#diff-3acb1faab911581f76591fac05ba92fd (especially function rnp_key_get_protection_type()
).
Would these be enough for you to recognize case where actual secret key data is absent?
Any news on this? As automatic update from TB68 to TB78 is coming closer, i'd be really happy to keep on using my GPG key in TB.
@fuelflo It is implemented on the RNP side, but not sure about the Thunderbird. Ping @kaie
This is broken in Thunderbird 78 unfortunately.
@STRML Honestly, I'm not sure whether this feature was picked by TB team already.
Okay. I ended up figuring out the issue - I was importing a key that contained several long-expired subkeys. After I removed those subkeys in GPG Keychain, and re-exported, the import into rnp/Thunderbird worked great.
@STRML Hm, that should not be an issue, at least for RNP - subkeys should be just marked as expired and unusable, but still imported.
The exact error was rnp_key_unprotect failed
, from https://hg.mozilla.org/comm-central/file/584545287aa2757e7596bc445359e81598e13eba/mail/extensions/openpgp/content/modules/RNP.jsm#l1672. I realize this is the wrong issue tracker, so consider this for informational purposes only :)
Honestly, I'm not sure whether this feature was picked by TB team already.
I came to this thread from https://bugzilla.mozilla.org/show_bug.cgi?id=1654893 while I was exploring if Thunderbird can work with an offline primary key (generated as in this tutorial), by signing using a sub-key.
For our case the sub-keys should be stored on an OpenPGP-compatible smart cards, which I believe[ref] are also unsupported.
Just as an update, unfortunately the higher priorities of other TB issues hasn't allowed me to work on this yet.
I came to this thread from https://bugzilla.mozilla.org/show_bug.cgi?id=1654893 while I was exploring if Thunderbird can work with an offline primary key (generated as in this tutorial), by signing using a sub-key.
Updated to version 78 today and I'm having the same issue. I also tried using the flag mail.openpgp.allow_external_gnupg and setup Thunderbid to use external GPG, but without luck.
antipatico@box:~$ thunderbird --version
Thunderbird 78.4.3
EDIT:
I just noticed this is completely off-topic, due to being under the RNP repo and not the Thunderbird one. Anyway I will leave it here since it may be useful with people incurring in the same problem.
After starting thunderbird for the third time, I actually got the Enigmail migration popup. It actually worked, and it presumably did this:
Now it seems like working, I hope it will help someone. Sorry for the off-topic.
Closing this as it implemented for a while, and needs to look nice in the 0.14 milestone. @kaie Feel free to reopen this or create an another issue.
This bug seems it might describe my scenario, described here:
https://wiki.debian.org/Subkeys?action=show&redirect=subkeys
However, if it does, it's not fixed in Tb 78.7.0 (64-bit), see screenshot.
$ thunderbird --version
Thunderbird 78.7.0
As suggested above.
$ uname -a
Linux mymachine 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1654893#c10 I've posted here in order to attach the screenshot which Tb bugzilla doesn't seem to provide for.
We received a request to support a configuration that uses an offline primary key. We don't need to support generating such a scenario. However, we want to support a scenario, in which the user uses gnupg to create their keys, and then imports all public keys, and then imports the secret keys of all subkeys, but not the secret key of the primary key.
Procedure used: gpg --full-gen-key select 4 (rsa sign only)
gpg --expert --edit-key addkey 4 addkey 6 save
gpg --export --armor > pub.asc gpg --export-secret-subkeys --armor > subkeys-sec.asc
Import pub.asc into Thunderbird -> works Import subkeys-sec.asc into Thunderbird -> fails
Errors on console: [get_packet_body_s2k() /home/user/moz/comm-esr78/mozilla/comm/third_party/rnp/src/librepgp/stream-packet.cpp:583] unknown s2k specifier [stream_parse_key() /home/user/moz/comm-esr78/mozilla/comm/third_party/rnp/src/librepgp/stream-packet.cpp:2201] failed to read key protection [process_pgp_key() /home/user/moz/comm-esr78/mozilla/comm/third_party/rnp/src/librepgp/stream-key.cpp:996] failed to parse key pkt at 0
Output of pgpdump of the secret key file starts with:
Old: Secret Key Packet(tag 5)(405 bytes) Ver 4 - new Public key creation time - Thu Jul 23 18:13:55 CEST 2020 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(3072 bits) - ... RSA e(17 bits) - ... Sym alg - Plaintext or unencrypted data(sym 0) GnuPG gnu-dummy (s2k 1001)