onnx icon indicating copy to clipboard operation
onnx copied to clipboard

[Feature request] SLSA V1.0 Level 2: Digital Signatures for Artifacts

Open jornfranke opened this issue 2 years ago • 3 comments

System information

Supply-chain Levels for Software Artifacts (SLSA V1.0) Level 2 requires to have digital signatures on build artifacts, such as Python packages.

I propose as part of this issue to implement signing for the ONNX Python packages. Cosign (https://github.com/SigStore/cosign) is a novel approach for signing build artifacts, such as containers. Cosign has been designed for signing software artifacts. It works without long-living private keys and thus it reduces the risk of misusing a private key for signing of malicious artifacts. It does so by linking a short-lived private key with OpenID Connect Identities.

An open question is which OpenID Connect Identity could be used. Github workflows for instance have one (cf. https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) - that could be an obvious candidate.

It has been also proposed for Pypi (e.g. https://yossarian.net/res/pub/pycon-2023.pdf). As a first step one can integrate the machinery of signing using cosign in the Github Action workflows.

Note: In https://github.com/onnx/onnx/issues/4046 I propose extension to the ONNX hub so it supports signing of ONNX models. This issue here is about signing of the ONNX python packages that are included by people in AI-based applications.

@andife thanks for providing some of the references

What is the problem that this feature solves?

  • Fullfilling part of SLSA v1.0 Level 2
  • Specifically: Prevents tampering after the build through digital signatures

Alternatives considered

There are no real alternatives to use digital signatures. However, there are alternatives how artifacts are signed. One popular alternative in other programming ecosystems (e.g. Java) is GPG - this is less popular in Python. According to this source less than 10%.

GPG singing requires usually long-living private keys, which can be leaked. Often the cryptoalgorithms are outdated because of this as the key was created long time ago.

GPG still has the issue that the trust of the key is based on the fact that it is manually imported into GPG. This means each developer, each pipeline needs to manually import a lot of keys for all packages that they need to trust.

Cosign addresses those issues by linking a short-lived key to an open id connect identity. Thus it cannot be leaked and for new package version always the latest secure cryptography standards can be used.

Describe the feature

It introduces higher security in the build process

Will this influence the current api (Y/N)?

No, only CI pipelines

Feature Area

CI pipelines

Are you willing to contribute it (Y/N)

Yes

Notes

No response

jornfranke avatar May 26 '23 19:05 jornfranke

We now have ability to sign models with Sigstore, please see https://github.com/google/model-transparency/tree/main/model_signing#onnx

Currently we're incubating this, testing to see if things are working properly, if all supported models work, etc. Plan is to then be able to integrate this as a library in ML frameworks to make signing and verification as transparent to the users as possible.

Please let us know if there are any pieces we're missing.

mihaimaruseac avatar Aug 23 '23 16:08 mihaimaruseac

I plan to integrate that during the process of improving the CI (https://github.com/onnx/onnx/pull/6246)

andife avatar Sep 13 '24 07:09 andife

That's exciting. Looking forward to it. Please let me know if there's anything we can help with.

mihaimaruseac avatar Sep 13 '24 13:09 mihaimaruseac