pypa / pypa/advisory-database

Standardise PyPI ecosystem reporting of Python runtime applicability

Open
#259 2 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Shell
Stars
370
Forks
111
Avg merge
3h 52m
Merged PRs (30d)
4

Description

https://github.com/pypa/pip-audit/issues/949 seemed like the wrong place to be having this conversation, so let's start again over here...

/CC @jenstroeger since you filed https://github.com/pypa/pip-audit/issues/949

/CC @keerthanap8898 who is the protagonist, I'm just support crew 😃

/CC @woodruffw FYI

In https://github.com/pypa/pip-audit/issues/949#issuecomment-3357268946:

There's the ecosystem_specific field, but that field requires OSV report creators to agree on a representation + actually use it.

This is a/the place to start trying to get some agreement on a standard for how the PyPI ecosystem will report on the Python runtime for vulnerabilities in the OSV format. They key stakeholders are going to be the OSV home databases that publish OSV records for the PyPI ecosystem:

  • Python Packaging Advisory Database
  • GitHub Advisory Database
  • OpenSSF Malicious Packages

OSV.dev doesn't need to validate this field and the data can be passed through unmodified to downstream consumers of it.

As one of the OSV schema maintainers, if necessary and helpful, we can look to specify something within the schema documentation, but I really don't think we're the right people to be telling how the aforementioned data publishers should be utilising this field. That should be a conversation between the data publishers and the data consumers. OSV Schema folks (like me) can certainly broker and participate in that conversation... I'm thinking of this as an ecosystem-specific sub-schema specification.

@keerthanap8898 proposed something in https://github.com/pypa/pip-audit/issues/949#issuecomment-3824029596

Image

My thoughts are it may be better to follow the existing affected field so that downstream consumers don't have to invent a new way of parsing the data in this field...

(We've currently got a prefix (PSF) for the Python runtime, but no ecosystem defined for it, so if we do go down that path, that's an additional administrative consideration)

Someone needs to take point on reaching consensus amongst the PyPI ecosystem stakeholders on both the format and the utilisation of it.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the linked pip-audit issue and the OSV Schema documentation for the ecosystem_specific and affected fields. Consult the Python Packaging Advisory Database, GitHub Advisory Database, and OpenSSF Malicious Packages perspectives; done means reaching stakeholder consensus on a PyPI runtime representation and its use.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.