Thanks to Michael Hanke for the following patch. Mailcrypt normally pipes the
plaintext into GPG, which means that GPG has no way of knowing the length of
the plaintext until encryption has finished. Thus it emits an encrypted packet
that indicates "unknown length". PGP2.x cannot handle this kind of length: it
requires that the length be known before decryption starts. To work around
this, GPG 1.0.2 and later offers the --set-filename and --set-filesize
options. This patch measures the size of the plaintext and uses these options
to make sure the resulting message can be decrypted by PGP2.x users (assuming
the message was encrypted to their RSA key, of course).
I'm working on integrating this into mailcrypt. My main concern is how to
gracefully handle earlier verisions of GPG that will choke on the new options.
But in the meantime, if you encrypt messages to PGP2.x users, use this patch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks to Michael Hanke for the following patch. Mailcrypt normally pipes the plaintext into GPG, which means that GPG has no way of knowing the length of the plaintext until encryption has finished. Thus it emits an encrypted packet that indicates "unknown length". PGP2.x cannot handle this kind of length: it requires that the length be known before decryption starts. To work around this, GPG 1.0.2 and later offers the --set-filename and --set-filesize options. This patch measures the size of the plaintext and uses these options to make sure the resulting message can be decrypted by PGP2.x users (assuming the message was encrypted to their RSA key, of course).
I'm working on integrating this into mailcrypt. My main concern is how to gracefully handle earlier verisions of GPG that will choke on the new options. But in the meantime, if you encrypt messages to PGP2.x users, use this patch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did a similar patch. Note that you have to count the input
properly or the signature does not verify.
And, you can *NOT* sign and encrypt in one step.
My recommendation is to make a new backend called
"pgp2-compat-gpg" and pick this backend for certain
recipients. Maybe the recipients can be marked in the
keyring somehow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
None
Thanks to Michael Hanke for the following patch. Mailcrypt normally pipes the
plaintext into GPG, which means that GPG has no way of knowing the length of
the plaintext until encryption has finished. Thus it emits an encrypted packet
that indicates "unknown length". PGP2.x cannot handle this kind of length: it
requires that the length be known before decryption starts. To work around
this, GPG 1.0.2 and later offers the --set-filename and --set-filesize
options. This patch measures the size of the plaintext and uses these options
to make sure the resulting message can be decrypted by PGP2.x users (assuming
the message was encrypted to their RSA key, of course).
I'm working on integrating this into mailcrypt. My main concern is how to
gracefully handle earlier verisions of GPG that will choke on the new options.
But in the meantime, if you encrypt messages to PGP2.x users, use this patch.
Thanks to Michael Hanke for the following patch. Mailcrypt normally pipes the plaintext into GPG, which means that GPG has no way of knowing the length of the plaintext until encryption has finished. Thus it emits an encrypted packet that indicates "unknown length". PGP2.x cannot handle this kind of length: it requires that the length be known before decryption starts. To work around this, GPG 1.0.2 and later offers the --set-filename and --set-filesize options. This patch measures the size of the plaintext and uses these options to make sure the resulting message can be decrypted by PGP2.x users (assuming the message was encrypted to their RSA key, of course).
I'm working on integrating this into mailcrypt. My main concern is how to gracefully handle earlier verisions of GPG that will choke on the new options. But in the meantime, if you encrypt messages to PGP2.x users, use this patch.
Logged In: YES
user_id=56602
I did a similar patch. Note that you have to count the input
properly or the signature does not verify.
And, you can *NOT* sign and encrypt in one step.
My recommendation is to make a new backend called
"pgp2-compat-gpg" and pick this backend for certain
recipients. Maybe the recipients can be marked in the
keyring somehow.