3 ms·

I just set up an apt repo of uv packages using GitHub Pages via Actions and wrote up some notes here: https://linsomniac.com/post/2025-03-18-building_and_publis

I just set up an apt repo of uv packages using GitHub Pages via Actions and wrote up some notes here: https://linsomniac.com/post/2025-03-18-building_and_publishing_apt_repos_to_github_pages/ https://linsomniac.com/post/2025-03-18-building_and_publishi... Looks like Simon and I were working on very similar things simultaneously.

westurner 2y ago
There should be a "Verify signature of checksums and Verify checksums" at "Download latest uv binary". GitHub has package repos; "GitHub Packages" for a few package formats, and OCI artifacts. https://docs.github.com/en/packages/working-with-a-github-packages-registry https://docs.github.com/en/packages/working-with-a-github-pa... OCI Artifacts with labels include signed Container images and signed Packages. Packages can be hosted as OCI image repository artifacts with signatures; but package managers don't natively support OCI image stores, though many can install packages hosted at GitHub Packages URLs which are referenced by a signed package repository Manifest on a GitHub Pages or GitLab Pages site (e.g. with CF DNS and/or CloudFlare Pages in front)
- linsomniac 2y ago
  >There should be a "Verify signature of checksums and Verify checksums" I get it, but verifying checksums of downloads via https from github releases, downloaded across github's architecture (admittedly Azure) to githubs's runners seems like overkill. Especially as I don't see any signatures of the checksums, so the checksums are being retrieved via that same infrastructure with the same security guarantees. What am I missing?
  - westurner 2y ago
    If downloading over https and installing were enough, we wouldn't need SLSA, TUF, or sigstore. .deb and .rpm Package managers typically reference a .tar.gz with a checksum; commit that to git signed with a GPG key; and then the package is signed by a (reproducible) CI build with the signing key for that repo's packages. conda-forge can automatically send a Pull Request to update the upstream archive URL and cached checksum in the package manifest when there is a new upstream package.
    - westurner 2y ago
      Actually, the conda-forge bot does more than that; From https://github.com/regro/cf-scripts/issues/3920#issuecomment-2746675003 https://github.com/regro/cf-scripts/issues/3920#issuecomment... re: (now github) dependabot maybe someday scanning conda environment.yml, conda-lock.yml, and/or feedstock meta.yml: > So the bot here does a fair bit more than update dependencies and/or versions. > We have globally pinned ABIs which have to migrated in a specific order. We also use the bot here to start the migrations, produce progress / error outputs on the status page, and then close the migrations. The bot here also does specific migrations of dependencies that have been renamed, recipe maintenance, and more. Dependabot scans for vulnerable software package versions in software dependency specification documents for a number of languages and package formats, when you git push to a repo which has dependabot configured in their dependabot.yml: From the dependabot.yml docs: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#package-ecosystem- https://docs.github.com/en/code-security/dependabot/working-... : > Define one package-ecosystem element for each package manager that you want Dependabot to monitor for new versions Dependabot supports e.g. npm, pip, gomod, cargo, docker, github-actions, devcontainers, SBOM tools have additional methods of determining which packages are installed on a specific server or container instance. Static sites are sometimes build and forget projects that also need regular review of the statically-compiled-in dependencies for known vulns. E.g. jupyterlite-xeus builds WASM static sites from environment.yml; though Hugo is probably much faster.

westurner 2y ago

There should be a "Verify signature of checksums and Verify checksums" at "Download latest uv binary". GitHub has package repos; "GitHub Packages" for a few package formats, and OCI artifacts. https://docs.github.com/en/packages/working-with-a-github-packages-registry https://docs.github.com/en/packages/working-with-a-github-pa... OCI Artifacts with labels include signed Container images and signed Packages. Packages can be hosted as OCI image repository artifacts with signatures; but package managers don't natively support OCI image stores, though many can install packages hosted at GitHub Packages URLs which are referenced by a signed package repository Manifest on a GitHub Pages or GitLab Pages site (e.g. with CF DNS and/or CloudFlare Pages in front)

linsomniac 2y ago
>There should be a "Verify signature of checksums and Verify checksums" I get it, but verifying checksums of downloads via https from github releases, downloaded across github's architecture (admittedly Azure) to githubs's runners seems like overkill. Especially as I don't see any signatures of the checksums, so the checksums are being retrieved via that same infrastructure with the same security guarantees. What am I missing?
- westurner 2y ago
  If downloading over https and installing were enough, we wouldn't need SLSA, TUF, or sigstore. .deb and .rpm Package managers typically reference a .tar.gz with a checksum; commit that to git signed with a GPG key; and then the package is signed by a (reproducible) CI build with the signing key for that repo's packages. conda-forge can automatically send a Pull Request to update the upstream archive URL and cached checksum in the package manifest when there is a new upstream package.
  - westurner 2y ago
    Actually, the conda-forge bot does more than that; From https://github.com/regro/cf-scripts/issues/3920#issuecomment-2746675003 https://github.com/regro/cf-scripts/issues/3920#issuecomment... re: (now github) dependabot maybe someday scanning conda environment.yml, conda-lock.yml, and/or feedstock meta.yml: > So the bot here does a fair bit more than update dependencies and/or versions. > We have globally pinned ABIs which have to migrated in a specific order. We also use the bot here to start the migrations, produce progress / error outputs on the status page, and then close the migrations. The bot here also does specific migrations of dependencies that have been renamed, recipe maintenance, and more. Dependabot scans for vulnerable software package versions in software dependency specification documents for a number of languages and package formats, when you git push to a repo which has dependabot configured in their dependabot.yml: From the dependabot.yml docs: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#package-ecosystem- https://docs.github.com/en/code-security/dependabot/working-... : > Define one package-ecosystem element for each package manager that you want Dependabot to monitor for new versions Dependabot supports e.g. npm, pip, gomod, cargo, docker, github-actions, devcontainers, SBOM tools have additional methods of determining which packages are installed on a specific server or container instance. Static sites are sometimes build and forget projects that also need regular review of the statically-compiled-in dependencies for known vulns. E.g. jupyterlite-xeus builds WASM static sites from environment.yml; though Hugo is probably much faster.