Supply chain / release security?

[mara004]

Is there any way to inherently guarantee that release artifacts were really created by a workflow, and not manually uploaded/edited?

The trouble is that GitHub does not seem to provide a way to freeze releases, and (I think) does not even show when a release has been edited (cf. https://github.com/orgs/community/discussions/51588).

Of course, I'm trusting you not to alter the releases in a bad way, but with computers theoretical security matters, and secure concepts are usually preferable over just trust.

This is mainly a GitHub issue IMHO, but is there anything we could do about it from our side, such as publishing to some other site that supports secure (non-editable) releases?

[mara004]

As said in orgs/community/discussions/51588 (comment), we could mirror this repository and make our own builds, but from a downstream perspective I believe this only shifts the trust problem to a different person, and it would seem like a real waste of CI resources to duplicate the builds.

[bblanchon]

You could check the artifacts checksum.
GitHub displays the sha256 of each artifact in the build page:
https://github.com/bblanchon/pdfium-binaries/actions/runs/15104097139#artifacts

[mara004]

Thanks for the suggestion!

I see the checksums are retained even after the artifacts expire, so that might be an option.
On the other hand, it looks like workflow history is somewhat limited, and the pages get deleted eventually, so it would only work for the more recent releases.

Also, I'm not sure if it's feasible to do this programatically (e.g. how to determine the matching build page for a release?). Anyway, I'll give this a try.

[mara004]

GitHub's REST API looks good.

We can get a JSON view of the release page via:

VERSION="7188"
curl "https://api.github.com/repos/bblanchon/pdfium-binaries/releases/tags/chromium%2F$VERSION"

To match against a workflow e.g. by date and commit hash:

DATE="2025-05-19"
COMMIT_HASH="8f0e5eaeac889cd269629dae6902478e8ddd7931"
curl "https://api.github.com/repos/bblanchon/pdfium-binaries/actions/workflows/build-all.yml/runs?created=$DATE&head_sha=$COMMIT_HASH"

And then list the artifacts:

RUN_ID="15104097139"
curl "https://api.github.com/repos/bblanchon/pdfium-binaries/actions/runs/$RUN_ID/artifacts"

[mara004]

I've written the verification code, but am running into checksum mismatches.
At a quick glance, the artifacts on the build page are .zip files, while the release artifacts are .tgz, so a mismatch is inevitable.

@bblanchon Is there any chance of getting the workflow and release artifacts to match exactly? Otherwise, Github's sha256 sums are not usable for verification.

FWIW, here's my code (for use in pypdfium2's update.py):

import json
import hashlib
import urllib.request as url_request

def log(*args, **kwargs):
    print(*args, **kwargs, file=sys.stderr)

def _gh_web_api(path):
    log(f"API Request {path}")
    with url_request.urlopen("https://api.github.com"+path) as h:
        return json.loads( h.read().decode() )

def _get_sha256sum(path):
    # TODO fallback for python < 3.11
    with open(path, "rb") as fh:
        return hashlib.file_digest(fh, "sha256").hexdigest()

def verify(archives, version):
    
    log("Attempt to verify release checksum against workflow ...")
    
    repo = "/repos/bblanchon/pdfium-binaries"
    date = _gh_web_api(f"{repo}/releases/tags/chromium%2F{version}")["published_at"][:10]
    
    # TODO also pass head_sha? (could be determined along tag in ls-remote call)
    runs = _gh_web_api(f"{repo}/actions/workflows/build-all.yml/runs?created={date}")
    assert runs["total_count"] == 1, runs["total_count"]
    run, = runs["workflow_runs"]
    
    artifacts_raw = _gh_web_api(f"{repo}/actions/runs/{run['id']}/artifacts")["artifacts"]
    artifacts_dict = {d["name"]: d for d in artifacts_raw}
    
    for path in archives.values():
        exp_sum = artifacts_dict[path.stem]["digest"].split(":", maxsplit=1)[1]
        file_sum = _get_sha256sum(path)
        if exp_sum == file_sum:
            log(f"SHA256 sums match: {file_sum}")
        else:
            raise SystemExit(f"Fatal: SHA256 sums don't match: {exp_sum} != {file_sum}")

[bblanchon]

I'm sorry; it totally slipped my mind that the build artifacts were the zipped folders and not the tarball.

I saw that we include a pdfium-sha256sum.txt with the release files (#173):
https://github.com/bblanchon/pdfium-binaries/releases/download/chromium%2F7188/pdfium-sha256sum.txt

The only problem is that you currently have no proof that this file hasn't been altered.
I will add it to the artifacts.

[mara004]

No worries, and thanks a lot for your cooperation on this!
Going through a checksums file sounds good, then we'd only have to ensure match for one artifact.
However, I think upload-artifact might implicitly zip the txt file again, so we'd have to include that exact same zip in the release – is that possible?

[mara004]

Also, it would be great if you could include the corresponding workflow ID somewhere on the release, as that would make downstream life a bit easier.

[ArcticLampyrid]

The trouble is that GitHub does not seem to provide a way to freeze releases, and (I think) does not even show when a release has been edited (cf. https://github.com/orgs/community/discussions/51588).

Maybe you can use SLSA to generate provenance and then release the provenance along with binaries.
Refer to https://github.com/slsa-framework/slsa-github-generator

[ArcticLampyrid]

Using the generic workflow will generate a non-forgeable attestation to the artifacts' digests using the identity of the GitHub workflow. This can be used to create a positive attestation to a software artifact coming from your repository.

That means that once your users verify the artifacts they have downloaded they can be sure that the artifacts were created by your repository's workflow and haven't been tampered with.

https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/generic/README.md

[bblanchon]

SLSA seems to be the way to go, but the amount of documentation is overwhelming!

If I understand correctly, I need to generate a base64 representation of the checksum file and pass this string to the generator_generic_slsa3 workflow.

However, I'm not sure if I should set upload-assets to true because most comments say "Upload provenance to a new release", so I wonder if it will create a duplicate release or update the existing one.
The alternative seems to be to download the artifact created by the generator_generic_slsa3 workflow and include it in the release artifacts.

[bblanchon]

I didn't find the time to set this up, so it's not included in today's build.
Hopefully, I'll get it ready for next week.