generated from ossf/project-template
-
Notifications
You must be signed in to change notification settings - Fork 49
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #197 from sethmlarson/psf-engagement-july-2023
Add PSF engagement update for July 2023
- Loading branch information
Showing
2 changed files
with
70 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,69 @@ | ||
# Update-2023-07 | ||
|
||
## Python Software Foundation as CVE Numbering Authority | ||
|
||
- Received approval from the Python Steering Council and pip maintainers to scope Python and pip under the prospective PSF CVE Numbering Authority (CNA). | ||
- Submitted registration for CNA onboarding and received onboarding date (August 21st) and materials from MITRE. | ||
- Discussed the creation of materials for CNA registration of open source projects with OSSF Vulnerability Disclosures WG. Aimed at creating "minimum-viable CNA" which can be run by volunteers. | ||
- Authored a Vulnerability Disclosure policy and machine-readable advisory database using OSV. | ||
- Documented CNA Rules, Onboarding, and Services (APIs) for other PSF CNA staff providing coverage. | ||
|
||
## Sigstore signed Python release artifacts | ||
|
||
- [Created a project](https://github.com/sethmlarson/verify-python-release-signatures/) | ||
which verifies Sigstore verification materials against Python release artifacts | ||
and the documentation of identities. Found [multiple issues](https://github.com/sigstore/sigstore-python/issues/600) | ||
with artifact signatures and mismatches with documentation. | ||
- Worked with release managers to create a plan for resigning artifacts correctly and updating the documentation | ||
to match the signatures of a release manager. Ended up with a table of (identity x provider) pairs for each release | ||
manager. Documentation and signatures now match up and verify consistently. | ||
- [Created an enhancement](https://github.com/python/release-tools/pull/51) to Python's release tools which will ensure | ||
Sigstore signatures will continue to be consistent with documentation. | ||
|
||
Separately from fixing the Sigstore signatures of Python, I also was interested in unifying disjoint Sigstore verification materials (`.crt`/`.sig`) | ||
and bundled Sigstore verification materials (`.sigstore`) in order to simplify the documentation on how to verify release artifacts. | ||
This was also motivated by `sigstore-python` moving to generated only bundles by default. | ||
|
||
- Migrating to bundles from existing disjoint materials currently isn't possible with `sigstore-python`, | ||
[created an issue](https://github.com/sigstore/sigstore-python/issues/718) with William Woodruff for this enhancement. | ||
This enhancement may be useful to [other implementations](https://github.com/sigstore/sigstore-python/issues/718#issuecomment-1654048226) | ||
to provide a migration path from disjoint matierals to bundles. | ||
- [Created an enhancement](https://github.com/sigstore/sigstore-python/pull/719) to `sigstore-python` for the internal API | ||
accomplishing this migration path. This will be enough to create a script to manually migrate disjoint materials to bundles | ||
for Python and will soon be available via CLI to others. | ||
|
||
## SBOMs and PEP 710 | ||
|
||
- [Created a dataset](https://github.com/sethmlarson/vendored-libraries-in-python-dists) which tracks non-Python artifacts bundled with top Python packages | ||
in order to better understand how different packages bundled non-Python dependencies. | ||
- Through this work discovered two vulnerabilities in Python packages due to bundling insecure versions of software that was accessible through the Python APIs. | ||
- [Wrote about the findings](https://sethmlarson.dev/security-developer-in-residence-weekly-report-2#bundled-libraries-in-python-distributions) from this initial discovery work and its applicability to manylinux and Python bundling tools. | ||
- [Reviewed PEP 710](https://discuss.python.org/t/pep-710-recording-the-provenance-of-installed-packages/25428/6?u=sethmlarson) (Package Provenance Info) and reached out to Fridolín Pokorný to | ||
collaborate on the PEP. This PEP has important applications in SBOMs by providing the hashes | ||
download URL, and index that a given package was installed from. | ||
- In order to prove the application of PEP 710, [created an experimental tool](https://github.com/sethmlarson/pip-sbom) that transforms the | ||
information provided by the POC that Fridolín created for the PEP into CycloneDX and SPDX SBOM formats. | ||
- Investigated [pip installation report format](https://pip.pypa.io/en/stable/reference/installation-report/) which is similar | ||
but requires specifying the packages to install rather than inspecting an already-installed environment. | ||
Added preliminary support for pip installation reports to the experimental tool as well. | ||
- Discussed with Dustin Ingram and Jeff Edwards who are authors of a [previous PEP draft](https://github.com/di/peps/blob/sboms/pep-9999.rst) | ||
on including SBOMs in Python wheels about collaborating on this work. Dustin agreed for me to lead another draft PEP | ||
going a different direction from the original draft. I am currently doing discovery work on this project. | ||
|
||
## Other items | ||
|
||
- Talk submission to OpenSSF Day Europe 2023 was [accepted](https://openssf.org/blog/2023/07/19/openssf-day-europe-agenda-now-live/). | ||
- Actively triaging disclosures for Python and pip via the Python Security Response Team (PSRT). | ||
Have been the active responder for all non-spam issues since joining PSRT. | ||
- Submitted a [vulnerability disclosure](https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w) to aiohttp | ||
which has been published as CVE-2023-30589. | ||
- [Submitted an update](https://github.com/pypa/packaging.python.org/pull/1277) to the PyPA binary distribution format specification to warn about interoperability issues with build numbers and security advisory formats. | ||
- [Created an enhancement](https://github.com/pypa/gh-action-pypi-publish/pull/167) to drive adoption of PyPI's Trusted Publisher feature by emitting a notice | ||
to users of GitHub Actions with API tokens or username/password to migrate to Trusted Publishers. | ||
Tracking the adoption of Trusted Publishers via [Warehouse metrics](https://github.com/pypi/warehouse/pull/14044). | ||
- Participated in a [discussion on `SSLContext.verify_flags` defaults](https://discuss.python.org/t/ssl-changing-the-default-sslcontext-verify-flags/30230/6?u=sethmlarson) | ||
- Authored weekly reports and shared on social media | ||
- https://sethmlarson.dev/security-developer-in-residence-weekly-report-2 | ||
- https://sethmlarson.dev/security-developer-in-residence-weekly-report-3 | ||
- https://sethmlarson.dev/security-developer-in-residence-weekly-report-4 | ||
- https://sethmlarson.dev/security-developer-in-residence-weekly-report-5 |