Skip to content

Update SPEC 8 - #438

Open
jarrodmillman wants to merge 7 commits into
scientific-python:mainfrom
jarrodmillman:spec8-updates
Open

jarrodmillman wants to merge 7 commits into
scientific-python:mainfrom
jarrodmillman:spec8-updates

Conversation

@jarrodmillman

@jarrodmillman jarrodmillman commented Oct 6, 2026 •

Copy link
Copy Markdown
Member

See #392 for more details.

@mihaimaruseac Feel free to suggest changes or push directly to my branch. Would you be okay adding your name as an author?

@henryiii Should we add anything about repo-review or your security skills? Feel free to suggest changes or push directly to my branch. Would you be okay adding your name as an author?

@sethmlarson Could you check my changes?

See scientific-python#392 for more details.
@jarrodmillman
jarrodmillman marked this pull request as draft October 6, 2026 15:41
Comment thread spec-0008/index.md Outdated
Comment thread spec-0008/index.md
Comment thread spec-0008/index.md Outdated
@mdhaber

mdhaber commented Oct 6, 2026

Copy link
Copy Markdown
Contributor

@andyfaff @tylerjereddy Thought you'd be the right people to ping about this - apparently SciPy hasn't endorsed SPEC 8. Does the SPEC and this update look good to you, and do you think we should move for SciPy to endorse it?

@mdhaber
mdhaber requested a review from tylerjereddy October 6, 2026 16:36
@lucascolley

Copy link
Copy Markdown
Contributor

worth a quick ping à la https://discuss.scientific-python.org/t/proposal-to-endorse-spec-7-seeding-prngs/1474 perhaps once this update is merged

@henryiii

henryiii commented Oct 6, 2026

Copy link
Copy Markdown
Contributor

Should we add anything about repo-review or your security skills?

We only have one check now (zizmor), but we do have one, so we could. For the security skill, maybe it should move somewhere first? Or we could add it now then work on moving it later.

Would you be okay adding your name as an author?

Sure.

@tylerjereddy

Copy link
Copy Markdown

Thought you'd be the right people to ping about this - apparently SciPy hasn't endorsed SPEC 8. Does the SPEC and this update look good to you, and do you think we should move for SciPy to endorse it?

I'd second Lucas' suggestion to ping on the discourse/mailing list. IIRC Ralf had stronger views than I on SPECs related to security matters, so would be good to see buy in there first.

I did look over the full diff here and the changes themselves seemed sensible enough.

Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
@jarrodmillman

Copy link
Copy Markdown
Member Author

Should we add anything about repo-review or your security skills?

We only have one check now (zizmor), but we do have one, so we could. For the security skill, maybe it should move somewhere first? Or we could add it now then work on moving it later.

@henryiii How about https://github.com/scientific-python/skills or https://github.com/scientific-python/sp-skills?

@matthewfeickert matthewfeickert left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for being the person who got to this @jarrodmillman! 🙇 Just a few questions and comments from me.

Comment thread spec-0008/index.md Outdated
Comment thread spec-0008/index.md Outdated
Comment thread spec-0008/index.md Outdated

@sethmlarson sethmlarson left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are other comments that captured my few questions, so I'll leave this as a LGTM, thanks!

jarrodmillman and others added 2 commits October 12, 2026 07:16
Co-authored-by: Matthew Feickert <matthew.feickert@cern.ch>
@jarrodmillman
jarrodmillman marked this pull request as ready for review October 12, 2026 14:31

@matthewfeickert matthewfeickert left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy with this. Thanks for the work @jarrodmillman!

Comment thread spec-0008/index.md
Co-authored-by: Matthew Feickert <matthew.feickert@cern.ch>
@jarrodmillman
jarrodmillman requested a review from stefanv October 12, 2026 22:00

@stefanv stefanv left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor questions, but broadly looks good to me, thanks!

Comment thread spec-0008/index.md
Using versions or small hashes is susceptible to attacks.
GitHub Actions must be pinned using the full commit SHA corresponding to the release version being used.
Using versions, branches, tags, or abbreviated hashes is susceptible to attacks.
Include the corresponding release version in a comment, and update pinned actions regularly through a reviewed process so that related actions remain compatible.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels to me like one of the weak points we have right now: dependabot makes a PR, someone merges it; who knows what that new version of the action contains?

Comment thread spec-0008/index.md
This replaces the need to use a long-lived token to authenticate, reducing the security risks associated with authentication tokens (e.g., tokens being compromised or needing to be rotated).

Trusted Publishers can be used in GitHub Actions by using the [`pypa/gh-action-pypi-publish`](https://github.com/pypa/gh-action-pypi-publish) GitHub Action defaults in a GitHub Actions environment.
When used with Trusted Publishing, this action generates and uploads [PEP 740](https://peps.python.org/pep-0740/) digital attestations by default, so a separate attestation step is not required.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By removing the above paragraph on attestation, do we still say, explicitly, that attestation is strongly recommended?

Comment thread spec-0008/index.md
print-hash: true
```

Projects that cannot use Trusted Publishing should still generate and publish provenance attestations where their build and distribution services support them.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be that sentence; worth moving earlier?

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

Successfully merging this pull request may close these issues.

8 participants