New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crypt::OpenPGP does not use encryption subkey, ignores key usage #9

Open
maertsen opened this Issue Jul 9, 2013 · 6 comments

Comments

Projects
None yet
6 participants
@maertsen

maertsen commented Jul 9, 2013

Crypt::OpenPGP does not use an encryption subkey if available and uses the primary (sign-only) key for encryption. This is unfortunate for those of us using the subkey mechanism to store the primary key offline; a Crypt::OpenPGP will consequently encrypt to a private key not available.
(And decrypting with a signing key would be unwise in any case)

I found out about this while trying to use the secure e-mail mechanism of Bugzilla (Mozilla's own instance). An independent bugreport was filed earlier [1]. A workaround consists of manually splitting public keys, but this is tedious and error-prone.

Is there any chance support for key usage could be implemented?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=790487

@hsivonen

This comment has been minimized.

hsivonen commented Aug 15, 2013

Specifically, I'd expected Crypt::OpenPGP to encrypt to the non-revoked encryption subkey whose expiry time is the furthest in the future.

@sergeyromanov

This comment has been minimized.

Collaborator

sergeyromanov commented Jun 12, 2014

Is there any chance support for key usage could be implemented?

Patches are very welcome at the very least!

@isislovecruft

This comment has been minimized.

isislovecruft commented Sep 6, 2014

For what it's worth, I think this bug stems from these lines:

my @valid = $pkg->all_props;
my %valid = map { $_ => 1 } @valid;

which map the key usage to the whether or not the key should be used according to subroutines like can_encrypt().

Since it appears that the Mozillians are too nice to say anything about it, this bug is blocking Mozilla bug 790487, which is causing the email report mechanism for security-critical bugs at Mozilla to not function correctly. Since I'm not a Mozillian, I don't mind pointing being the asshole who points out that you're fucking their shit up.

@towo

This comment has been minimized.

towo commented Oct 18, 2016

FWIW, this is not entirely correct. The test e-mail gets sent successfully and to the right address, just other mails are an issue.

@towo

This comment has been minimized.

towo commented Nov 29, 2016

Another FYI update - we assumed this was a partial bug related to this, but the most "recent" version of the securemail extension (https://github.com/bugzilla/extensions-SecureMail) solved our issues.

@sysrqb

This comment has been minimized.

sysrqb commented Apr 14, 2018

This is still a problem. I just received an email from bugzilla.mozilla.org encrypted using my primary public key. Has anyone looked at this? Is Isis' suggestion regarding what's causing this wrong or was it ignored?

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment