Skip to content
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

Promote cosign to public API (and support bzlmod) #235

Open
seh opened this issue May 10, 2023 · 8 comments
Open

Promote cosign to public API (and support bzlmod) #235

seh opened this issue May 10, 2023 · 8 comments
Labels
enhancement New feature or request

Comments

@seh
Copy link
Contributor

seh commented May 10, 2023

In #36 we introduced support for using the cosign tool with the cosign_attest and cosign_sign rules. Both of those require a registered toolchain for cosign. The cosign/repositories.bzl file defines the cosign_register_toolchains macro, but it remains difficult to use in a WORKSPACE.bzlmod file. Ideally we would register a toolchain for cosign in the MODULE.bazel file like we do for crane.

In short, it would be good to be able to use cosign as easily as we can the other tools integrated by this module.

@alexeagle
Copy link
Collaborator

Yup, cosign is a "private API" in 1.0. Only the distroless team is using it. Adding bzlmod support is just one of the tasks for considering it "ready" to commit to support in the public API surface.

@alexeagle alexeagle changed the title Allow use of cosign toolchain via MODULE.bazel file Promote cosign to public API (and support bzlmod) May 10, 2023
@alexeagle alexeagle added this to the 1.1 milestone May 10, 2023
@farcop
Copy link

farcop commented Nov 26, 2023

We want to use cosign_attest rule too, but unable to generate SBOM bazel way.
I have created chainguard-dev/rules_apko#35

@thesayyn thesayyn removed this from the 1.1 milestone Dec 12, 2023
@thesayyn thesayyn added the enhancement New feature or request label Dec 12, 2023
@seh
Copy link
Contributor Author

seh commented Jun 12, 2024

Coming back to this desire, has there been any movement on exposing cosign that isn't mentioned here?

@thesayyn
Copy link
Collaborator

Not really, i am not sure if cosign belongs here anymore. Only reason for keeping it is distroless, i thought about moving it to rules_distroless.

@farcop
Copy link

farcop commented Jun 12, 2024

We would really like to use this

+UPD. We dont use rules_distroless, we use rules_apko instead, so it’s logical to do it here

@seh
Copy link
Contributor Author

seh commented Jun 12, 2024

Only reason for keeping it is distroless, i thought about moving it to rules_distroless.

You're far more familiar with the domain than I am, but this surprised me, as it's not clear to me what cosign has to do with distroless. I'm looking to sign my container images, whether or not the images are based on distroless.

If not here, then a dedicated rules_cosign ruleset would make sense, though I expect that it would rather small, paying the outsized tax of needing its own CI workflow, BCR integration, and releases.

@dsupru
Copy link

dsupru commented Jul 1, 2024

Need this as well
We use oci_image to make images, would make sense from a user's point of view to also sign it

Does it have to be a separate rule ?
(from a user's point of view) Would be nice to just have something like:

oci_image(
    name = "image",
    ...
    cosign_sign = "<define how to sign it here: path to the private key, etc..>"
)

@alexeagle
Copy link
Collaborator

If anyone has time to contribute this or can track down some OSS funding from their organization, that would be great. Primary maintainers here currently don't have volunteer time for it.

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

No branches or pull requests

5 participants