Bugzilla

Justus, it seems you are offended, but I don't understand why you are offended.

Maybe my use of the word "challenge" wasn't clear?
I'm using "challenge" in the sense of "here we have a problem that is difficult to solve".

With "challenge presented in comment 4" I intended to say, this is what we need to solve, and I don't understand yet what we need to solve.

In comment 6, I intended to say, comment 5 doesn't yet help me to understand how to solve it using a combination of GnuPG and RNP.

This bug has been filed against Thunderbird, that means, the purpose of this bug is to find a solution that can be implemented based on the technologies that Thunderbird uses.

I'll appreciate constructive suggestions for how to solve it. If we can find a way to solve it, then we could consider to implement it and switch Thunderbird to use the combined approach.

To reiterate, we must create the signature using GnuPG, and we want to create the encryption using RNP. This is because currently Thunderbird doesn't want to use GnuPG for public key operations like encryption, because it wants to manually handle the decision which public keys are acceptable, and doesn't do management of public keys in the GnuPG database.

We already have a solution for the secret key operation (GPGME). Suggesting a different approach for performing the secret key operation (you suggested to use gpg-agent) doesn't seem to help reaching the goal of this bug.

What we'd need is a mechanism inside the RNP library. That's my understanding. We'd need an API inside the RNP library to say: Take this signed OpenPGP message, and transform it into a signed+encrypted message, encrypted to the following set of public keys available in the RNP keyring.

Justus, it seems you are offended, but I don't understand why you are offended.

Maybe my use of the word "challenge" wasn't clear?
I'm using "challenge" in the sense of "here we have a problem that is difficult to solve".

With "challenge presented in comment 4" I intended to say, this is what we need to solve, and it's not yet clear how we can solve it. [edited sentence to clarify]

In comment 6, I intended to say, comment 5 doesn't yet help me to understand how to solve it using a combination of GnuPG and RNP.

This bug has been filed against Thunderbird, that means, the purpose of this bug is to find a solution that can be implemented based on the technologies that Thunderbird uses.

I'll appreciate constructive suggestions for how to solve it. If we can find a way to solve it, then we could consider to implement it and switch Thunderbird to use the combined approach.

To reiterate, we must create the signature using GnuPG, and we want to create the encryption using RNP. This is because currently Thunderbird doesn't want to use GnuPG for public key operations like encryption, because it wants to manually handle the decision which public keys are acceptable, and doesn't do management of public keys in the GnuPG database.

We already have a solution for the secret key operation (GPGME). Suggesting a different approach for performing the secret key operation (you suggested to use gpg-agent) doesn't seem to help reaching the goal of this bug.

What we'd need is a mechanism inside the RNP library. That's my understanding. We'd need an API inside the RNP library to say: Take this signed OpenPGP message, and transform it into a signed+encrypted message, encrypted to the following set of public keys available in the RNP keyring.

Justus, it seems you are offended, but I don't understand why you are offended.

Maybe my use of the word "challenge" wasn't clear?
I'm using "challenge" in the sense of "here we have a problem that is difficult to solve".

With "challenge presented in comment 4" I intended to say, this is what we need to solve, and it's not yet clear how we can solve it. [edited sentence to clarify]

In comment 6, I intended to say, comment 5 doesn't yet help me to understand how to solve it using a combination of GnuPG and RNP.

This bug has been filed against Thunderbird, that means, the purpose of this bug is to find a solution that can be implemented based on the technologies that Thunderbird uses.

I'll appreciate constructive suggestions for how to solve it. If we can find a way to solve it, then we could consider to implement it and switch Thunderbird to use the combined approach.

To reiterate, when using the external GnuPG configuration, we must create the signature using GnuPG, and we want to create the encryption using RNP. This is because currently Thunderbird doesn't want to use GnuPG for public key operations like encryption, because it wants to manually handle the decision which public keys are acceptable, and doesn't do management of public keys in the GnuPG database.

We already have a solution for the secret key operation (GPGME). Suggesting a different approach for performing the secret key operation (you suggested to use gpg-agent) doesn't seem to help reaching the goal of this bug.

What we'd need is a mechanism inside the RNP library. That's my understanding. We'd need an API inside the RNP library to say: Take this signed OpenPGP message, and transform it into a signed+encrypted message, encrypted to the following set of public keys available in the RNP keyring.