Coder Social home page Coder Social logo

sigstore / gh-action-sigstore-python Goto Github PK

View Code? Open in Web Editor NEW
45.0 6.0 10.0 109 KB

A GitHub Action for sigstore-python

Home Page: https://github.com/marketplace/actions/gh-action-sigstore-python

License: Apache License 2.0

Makefile 3.54% Python 77.01% Shell 19.45%
codesigning github-actions security supply-chain

gh-action-sigstore-python's Introduction

sigstore framework

Fuzzing Status CII Best Practices

sigstore/sigstore contains common Sigstore code: that is, code shared by infrastructure (e.g., Fulcio and Rekor) and Go language clients (e.g., Cosign and Gitsign).

This library currently provides:

  • A signing interface (support for ecdsa, ed25519, rsa, DSSE (in-toto))
  • OpenID Connect fulcio client code

The following KMS systems are available:

  • AWS Key Management Service
  • Azure Key Vault
  • HashiCorp Vault
  • Google Cloud Platform Key Management Service

For example code, look at the relevant test code for each main code file.

Fuzzing

The fuzzing tests are within https://github.com/sigstore/sigstore/tree/main/test/fuzz

Security

Should you discover any security issues, please refer to sigstores security process

For container signing, you want cosign

gh-action-sigstore-python's People

Contributors

bobcallaway avatar dependabot[bot] avatar di avatar jeanchristophemorinperso avatar jku avatar rajbos avatar semgrep-bot avatar tetsuo-cpp avatar tnytown avatar woodruffw avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar

Forkers

di mbestavros mayacostantini bobcallaway trail-of-forks tnytown dk96-os jku

gh-action-sigstore-python's Issues

Add a setting to disable `.crt` and `.sig` outputs

From #46: these outputs are now redundant against .sigstore, but are included by default for backwards compatibility.

As such, we should add a setting (maybe bundle-only: bool or similar?) that allows a user to disable them if they don't need them and don't want them cluttering up their releases.

Not all inputs are signed starting with 2.0.0

Description

I recently updated from 1.2.3 to 2.0.0 and noticed not all of the inputs are being signed.

I'd have expected the pywemo-1.2.1.tar.gz and pywemo-1.2.1-py3-none-any.whl file from ./${DIST_ARTIFACT}/* to have been signed too. I've attached the signing-artifacts-sigstore.zip and the dist-ubuntu-latest-3.8.zip (./${DIST_ARTIFACT}/) build artifacts.

I wonder if something changed recently with environment variable expansion, or globbing, for the inputs? This workflow had been working with version 1.2.3.

Flip the `release-signing-artifacts` default

This is currently false by default, but arguably it should be true: a user who uses this action in the context of a release: published event is probably expecting their signatures to be uploaded to the release, and shouldn't have to explicitly opt into it.

Allow inputs to be empty if release-signing-artifacts is true

Description

Hello, right now the inputs input has to be provided by users. But there is scenarios where projects don't necessarily produce any artifact as part of their releases but they would still like they zip and tar file created by GitHub on every release to be signed.

I imagine that

- name: Sign artifacts
  uses: sigstore/gh-action-sigstore-python
  with:
    release-signing-artifacts: true

could potentially be allowed? Or is this outside the scope of this action and projects are expected to do something like

- name: Create source archive
  run: gh release download $RELEASE_TAG --dir release_artifacts
  env:
    RELEASE_TAG: ${{ github.ref_name }}

- name: Sign artifacts
  uses: sigstore/gh-action-sigstore-python
  with:
    inputs: ./*
  working-directory: release_artifacts

- name: Upload signed artifacts on the release
  run: gh release upload --clobber $RELEASE_TAG *
  env:
    RELEASE_TAG: ${{ github.ref_name }}
  working-directory: release_artifacts

instead?

Dependabot Updates Configuration

Description

I noticed that you recently added a dependabot config file.

I looked into it and I saw that you added the github actions package ecosystem to get updates in your .github/workflow/ files.

Did you know you can add the pip package ecosystem as well? That's what I did on my fork, and I received an update to the requests dependency in the requirements.txt file.

It seems to be an important update. Here is the link: Requests

I am ready to create a quick PR and merge the updates from my fork's main branch if you would like.

Action fails with `python-sigstore` error

Received this output from a run of the action (run linked here:

❌ sigstore-python failed to sign package
❌ sigstore-python verification skipped due to failed signing
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.10.6/x64/lib/python3.10/runpy.py", line 1[96](https://github.com/mbestavros/supply-chain-pipeline-demo/actions/runs/3063310998/jobs/4945242878#step:8:99), in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/hostedtoolcache/Python/3.10.6/x64/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/opt/hostedtoolcache/Python/3.10.6/x64/lib/python3.10/site-packages/sigstore/__main__.py", line 22, in <module>
    main()
  File "/opt/hostedtoolcache/Python/3.10.6/x64/lib/python3.10/site-packages/sigstore/_cli.py", line 257, in main
    _sign(args)
  File "/opt/hostedtoolcache/Python/3.10.6/x64/lib/python3.10/site-packages/sigstore/_cli.py", line 382, in _sign
    result = signer.sign(
  File "/opt/hostedtoolcache/Python/3.10.6/x64/lib/python3.10/site-packages/sigstore/_sign.py", line [101](https://github.com/mbestavros/supply-chain-pipeline-demo/actions/runs/3063310998/jobs/4945242878#step:8:104), in sign
    verify_sct(
  File "/opt/hostedtoolcache/Python/3.10.6/x64/lib/python3.10/site-packages/sigstore/_internal/sct.py", line 279, in verify_sct
    hash_algorithm, signature_algorithm, signature = _sct_properties(sct, raw_sct)
  File "/opt/hostedtoolcache/Python/3.10.6/x64/lib/python3.10/site-packages/sigstore/_internal/sct.py", line 82, in _sct_properties
    sct.hash_algorithm,  # type: ignore[attr-defined]
AttributeError: 'builtins.Sct' object has no attribute 'hash_algorithm'

Possibly a dependency error? I wasn't running into this issue before.

Scheduled selftest workflow

Description

In #63, our test suite caught an issue related to a breaking change in TUF. To catch these things earlier, we should run the selftest workflow on a schedule.

Support globbing for inputs argument

A common use case will be to sign a series of files based on a pattern. We'd ideally like to support inputs like:

- uses: trailofbits/[email protected]
  with:
    inputs: dist/*.tar.gz dist/*.whl

We'll likely need to interpret the * symbol in action.py to behave this way. Look into the glob and fnmatch modules to start with as these probably be helpful for implementing globbing.

Remove `no-default-files`?

I'm not sure it makes sense for us to expose this CLI flag as an action setting -- the user can simply choose not to use any artifacts/assets if they don't care about the default file outputs.

Thoughts @tetsuo-cpp?

Expose `sigstore verify` functionality

So far, this Action is purely about code signing via sigstore sign invocations. However, from the little that I've seen, users seem interested in verifying signatures immediately after publishing as a form of validation.

Expose the signature and certificate outputs in various ways

We should think about how we want to expose these outputs, beyond placing them on the filesystem. Some ideas:

  • Create job outputs corresponding to each artifact.
    • Downsides: Job outputs aren't really intended for this, plus the naming with multiple inputs will be tricky.
  • Create workflow artifacts corresponding to each artifact.
    • Downsides: None?
  • Support attaching each artifact to the associated GitHub Release, if our action is run on a release workflow.
    • This should be configurable, not the default.

Cache TUF metadata and artifacts

It would be useful to cache TUF metadata and the downloaded artifacts:

  • less downloading is better for everyone
  • cached metadata is slightly more secure

In practice this would mean mean using https://github.com/actions/cache with the sigstore application data dir and cache dir (or at least the tuf relevant subdirs) as the cache paths. It would make sense to verify that the cache is getting used with some debug logging in the self test (I'm assuming the default logging doesn't show this).

I'm filing this now so I don't forget: I'll likely take a stab at this later myself if no-one has implemented by then

Artifact/release asset upload should include the signed inputs

I just noticed this: we upload the signing outputs (cert, sig, bundle, etc.), but never the actual inputs that they're produced from (unless they're the default release assets).

For example, here are the uploaded assets from a release of abi3audit: we have verification materials for the wheel and sdist, but the wheel and sdist are not themselves attached.

As a fix, we should attach every input we sign for. This shouldn't be a serious size/duplication issue, since GitHub's object storage will do deduplication for us under the hood.

Screenshot 2023-03-08 at 10 14 06 AM

Split inputs using `shlex.split`

We currently split the inputs passed by the user using str.split, which will be wrong for some inputs (e.g., if the user passes in a filename containing whitespaces). We should instead use shlex.split.

Suport for `**` globs

We don't currently support these, but they'd be trivial to add. Just filing an issue so I don't forget.

Add a separate verification mode

Right now we support a verify option during signing, but not a completely separate verification mode (i.e., where the inputs are verification materials, and all the action does is verify them).

I think this would be useful to have -- it'd help drive "low-effort" adoption of Sigstore signatures, and could be used to write "beacon"-style automated validators for various ecosystems (e.g., ensuring that every CPython release has a valid signature).

cc @tetsuo-cpp and @di for thoughts.

Add more self tests to CI

Let's add more invocations of sigstore-python that exercise the different CLI options. At the moment, we just sign ./tests/artifact.txt in the prod and staging instances.

action.py: No such file or directory

Description

I keep getting an error using the most barebones configuration, I will skip to the part when the runner finishes installing all dependencies and tries to run the sigstore action.

Run D:\a\_actions\sigstore\gh-action-sigstore-python\v1.2.3/action.py "./build/test.dist/test.exe"
D:\a\_temp\4cbeed94-1ea6-46c1-a605-345eda4ef060.sh: line 1: D:a_actionssigstoregh-action-sigstore-pythonv1.2.3/action.py: No such file or directory
Error: Process completed with exit code 127.

Note: Isn't this D:a_actionssigstoregh-action-sigstore-pythonv1.2.3/action.py path kind of broken? I feel like it's missing a backslash or two. Maybe this action is not suitable for a windows runner?

I tested on this workflow.

name: Python application

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read
  id-token: write

jobs:

  build:
    # Windows is currently the only platform Nuitka action supports apparently?
    runs-on: windows-latest

    steps:

      # Check-out repository
      - uses: actions/checkout@v3

      # Setup Python
      - uses: actions/setup-python@v4
        with:
          python-version: '3.10' 
          architecture: 'x64' 

      - name: Compile to executable
        uses: Nuitka/Nuitka-Action@main
        with:
          nuitka-version: main
          script-name: test.py
          standalone: true
          onefile: false


      - name: Sign
        uses: sigstore/[email protected]
        with:
          inputs: build/test.dist/test.exe 

      # Uploads artifact
      - name: Upload Artifact
        uses: actions/upload-artifact@v3
        with:
          name: Windows Build
          path: build/test.dist

Note: The input path seems to be correct, as removing the whole signing step uploads the artifact correctly.

Version

[email protected]
windows-latest

release-signing-artifacts fails on push tags trigger

Description
If you enable release-signing-artifacts in push tags triggered flow if fails with:

Traceback (most recent call last):
  File "/home/runner/work/_actions/sigstore/gh-action-sigstore-python/v2.1.1/action.py", line 194, in <module>
    artifact = _download_ref_asset(filetype)
  File "/home/runner/work/_actions/sigstore/gh-action-sigstore-python/v2.1.1/action.py", line 74, in _download_ref_asset
    r.raise_for_status()
  File "/opt/hostedtoolcache/Python/3.10.13/x64/lib/python3.10/site-packages/requests/models.py", line 1021, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://github.com/....

From the docs I couldn't find any indication that this should only be used with a different trigger criteria.

Version

v2.1.1

_download_ref_asset does not handle file separators in branch names

Description

Hi, I'm currently experimenting with sigstore releases on a branch named ci/release-workflow in one of my repos. I got the following error on my first test run:

Traceback (most recent call last):
  File "/home/runner/work/_actions/sigstore/gh-action-sigstore-python/v1.2.3/action.py", line 189, in <module>
    artifact = _download_ref_asset(filetype)
  File "/home/runner/work/_actions/sigstore/gh-action-sigstore-python/v1.2.3/action.py", line 70, in _download_ref_asset
    with artifact.open("wb") as io:
  File "/usr/lib/python3.10/pathlib.py", line 1119, in open
    return self._accessor.open(self, mode, buffering, encoding, errors,
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/ci/release-workflow.zip'

Looking at the code, this line seems to be the culprit:

gh-action-sigstore-python/action.py

Line 65 in e323e1b

artifact = Path(f"/tmp/{os.getenv('GITHUB_REF_NAME')}.{ext}")

GITHUB_REF_NAME is ci/release-workflow in my case, so the path is rendered as /tmp/ci/release-workflow.zip, which results in a file not found error because the /tmp/ci directory doesn't exist.

Suggest either of the following:

  • Sanitise the refname to remove/replace characters that can't appear in file names
  • Create all parent directories prior to writing the file

Version

v1.2.3 of this GitHub action :)

Figure out how to sign for the default release assets

By default, GitHub Actions produces {tag}.tar.gz and {tag}.zip assets for each release.

These artifacts are generated on the fly, meaning that they can (and have) changed their contents (and thus digests) over time. This recently caused some significant breakage due to incorrect assumptions around that: https://github.blog/changelog/2023-01-30-git-archive-checksums-may-change/

Given that they can change, the correct thing for us to do here is probably to download the asset as it appears, sign for it, and then re-upload it to the release as a new asset: this will freeze it, meaning that the signature will remain correct.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.