How to strip Cosign binary

[xukey]

Question

Hello folks,
I'm going to build Cosign for an ARM platform(arm64). The built Cosign binary file size is about 90MB, it is huge for an embedded system. I'd like to know how to strip Cosign binary?

1. Is there any utility to use to strip?
2. Is there any configuration of Cosign? that I can disable some unnecessary features .

$ls -l cosign_main
-rwxr-xr-x 1 user group 93551876 May 15 18:54 cosign_main

$file cosign_main
cosign_main: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=CYUqkmlUu-7JLCRPLAdT/mUx0-sdmxjSBWcNmWoAz/P9QThBynvtiwOv_hIDiV/D8xAS0KX8jzhubvg9oiL, with debug_info, not stripped

Best regards,
Kxu

[ChristianCiach]

This may or may not be related to

• Plan for sget! #1363
  and also somewhat
• cosign as a library #666

I agree with @xukey, cosign is too fat for some use-cases. Do we really need a singe tool to both sign/attach and verify/download stuff? Signing/attachting is usually done on producer-side, while the consumers only want to verify/download artifacts.

I am fully aware that I may be way too naive here. I guess the largest chunk of the binary is made up of (transitive) dependencies that are probably necessary for both signing and verifying. Still, this binary size is an issue for us as well.

[ChristianCiach]

Totally related to

• Sanitize cosign's dependency tree #1462

[znewman01]

There's also the issue that Cosign is responsible for all of:

• core Sigstore infra logic
• interacting with OCI registries
• interacting with every KMS provider
• interacting with OIDC
• both sign/verify logic

These bulk up the dependency tree quite a bit. Another effort that may help here is sigstore-go: the idea being that if you don't need OCI you can omit many of the dependencies.

I think it's sensible to have "light" builds of Cosign that omit certain functionality, but it's a fair bit of work to set up and maintain, so I don't foresee that happening in the short-term unfortunately, unless someone's available to do a fair bit of refactoring.

I think the medium-term plan for sigstore-go will require such refactoring, and we may see this happen as part of that effort (which is on the sig-clients roadmap).

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.

[mattdibi]

Hello there,
resurrecting the issue since we have the same issue as @xukey. For embedded system 100MB binaries are just too much. Is there a way to strip the cosign binary so that it allows us to perform the verify without additional dependencies? If not, is there an alternative we can use?

[haydentherapper]

Hey, if you're doing verification of binaries, take a look at https://github.com/sigstore/sigstore-go, which is a much smaller package and a clean room implementation of the verification logic.

Given the number of cloud and OCI dependencies, I don't see how to quickly decrease the size of Cosign without moving towards a plugin system. This is something we'd like to do at some point, but it'll take time.

[mattdibi]

Hi @haydentherapper thank for the quick reply. Our main goal is to perform the verification of container image signature which, by what you write, seems to be outside the scope of sigstore-go...

[haydentherapper]

There's actually an example of verification of OCI in https://github.com/sigstore/sigstore-go/tree/main/examples/oci-image-verification, @rdimitrov might be able to provide more pointers

[rdimitrov]

hey, @mattdibi 👋 We were using cosign initially, but once we made the switch to sigstore-go we were quite happy to see it cut around 30% of our image size, i.e. it was ~94mb before and after the switch it slimmed down to ~60mb. Here's the code we now use in stacklok/minder.

Feel free to reach out if I can help in some way 👍 I'll probably write a short blog post soon about this so that might be helpful too.

Thanks for the ping @haydentherapper 👍