Skip to content

Support IMA file singing for built packages #205

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

Open
dralley opened this issue Dec 19, 2023 · 5 comments
Open

Support IMA file singing for built packages #205

dralley opened this issue Dec 19, 2023 · 5 comments

Comments

@dralley
Copy link
Collaborator

dralley commented Dec 19, 2023

We already support getting the IMA signatures from existing packages, but we don't support adding IMA signatures to new packages being built.

@baloo
Copy link
Contributor

baloo commented Apr 4, 2025

I'd like to take a swing at this one.

@dralley
Copy link
Collaborator Author

dralley commented Apr 5, 2025

Go for it!

@dralley
Copy link
Collaborator Author

dralley commented Apr 5, 2025

@baloo However, try not to conflict too much with #264. If you can wait a couple of days until it's merged, or base your work on top of it, that would be great

@dralley
Copy link
Collaborator Author

dralley commented Apr 5, 2025

@baloo
Copy link
Contributor

baloo commented Apr 5, 2025

Like I’ve done in #244 I’d like to make it so that the private key signing the ima attributes can be held on an HSM. I think it’s should be fairly easier to do than with pgp, and that just accepting a signer that implements a signature::DigestSigner should do (probably also going to require signature::KeyPair to autocompute the key id (which from my current understanding is the 4 last bytes of the spki digest). That should be transparent to whether the key is directly held in software or behind an HSM or a smart card (yubikey,…).

I’m considering making imaevm crate just to separate the signing logic and not embedded it here. (IMA has a couple revisions of its signature scheme and I’m not sure it makes sense to embed that logic here).

Anyway, this is my current train of thoughts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants