Evaluate

This page is for the people who have to sign off on the software, not write against it. Everything below is checkable from outside the project — you do not have to take the maintainer’s word for any of it.

What this project does not claim

Pacsmith is early development (v0.3.1) and is not production-ready. It is an independent open-source project: nothing here is certified, approved or endorsed by the Federal Reserve or any other operator, and no compatibility with the FedNow® Service is guaranteed. Pre-1.0 minor versions may break APIs. Evaluate it as what it is — a reference toolchain you run yourself, under a licence that disclaims warranty.

Verifying a release

Releases are signed keylessly with Sigstore: there is no private key and no signing secret in the repository. The release workflow exchanges its short-lived GitHub Actions OIDC token for an ephemeral certificate, signs with it, and the signature is recorded in the public Rekor transparency log. The certificate binds the signature to that workflow, in that repository, at that tag — which is exactly what the command below checks.

You need cosign v3 or newer. Nothing else: no key to fetch, no keyring to trust.

Verify a release artifact

$ TAG=v0.3.1   # the release you downloaded
$ cosign verify-blob \
    --bundle "fednow-oss-$TAG-x86_64-linux.tar.gz.cosign.bundle" \
    --certificate-identity "https://github.com/joaoabuenosi/fednow-oss/.github/workflows/release.yml@refs/tags/$TAG" \
    --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
    "fednow-oss-$TAG-x86_64-linux.tar.gz"

Verified OK is the only acceptable output. Anything else is a failure — do not use the artifact.

Note

That command is not typed into this page. It is extracted from SECURITY.md when the site is built, so the command shown here and the command in the security policy cannot drift apart. If the policy’s verification section ever moves or changes shape, the site build fails instead of publishing a command that does not work.

Signing starts with v0.3.1. Earlier releases carry no signature bundle, and v0.3.0 has no assets at all — its release run failed before the artifacts were produced. Use v0.3.1 or later. The security policy has the full detail, including why checksums alone prove nothing about origin.

Software Bill of Materials

Every signed release ships two SBOMs of the same build:

Asset	Format
fednow-oss-<tag>.cdx.json	CycloneDX
fednow-oss-<tag>.spdx.json	SPDX

Both are signed with the same keyless flow as the binaries, so an SBOM can be verified with the command above — swap the filenames. SHA256SUMS covers the tarball and both SBOMs, and is signed too. The security policy has the full asset table, including how each SBOM is produced.

Dependency advisories are not left to release time: cargo audit runs on every lockfile change and daily, and Dependabot opens weekly update pull requests.

OpenSSF Scorecard

The OpenSSF Scorecard runs weekly and on every push to main, publishes to the public OpenSSF API, and uploads its findings to the repository’s code scanning tab. The badge above is served by OpenSSF, not by this site — it shows the current score whether or not that score is flattering.

Raising it is ongoing work rather than a finished job: the most recent step was #84, which pinned every third-party action to a commit SHA and scoped every workflow’s permissions, and the checks still counting against the score are being closed the same way.

Pinning is enforced, not just claimed

Every third-party action in every workflow is pinned to a 40-character commit SHA carrying a # <version> comment, and every workflow starts from permissions: {} with per-job scopes. Neither is a promise someone has to remember to keep: both are checked on every CI run by check-workflow-hardening.sh, which fails the build if a workflow gains an unpinned uses: or loses its top-level permissions: key. Read it at the source in SECURITY.md, or check the workflows themselves.

Reporting a vulnerability

Do not open a public issue for a security problem.

• Preferred: GitHub private vulnerability reporting — the “Report a vulnerability” button under the repository’s Security tab.
• If you cannot use GitHub: email the maintainer with the subject given in the policy.

Acknowledgement within 72 hours, a triage verdict within 7 days, fix timelines agreed case by case. Credit in the release notes and a CVE where applicable, unless you would rather stay anonymous. The full policy has the scope notes, including what is explicitly out of scope.

Talk to the maintainer

Pacsmith is built and maintained by one person, in the open. If you are at a bank or a credit union weighing this up, these conversations are welcome — and genuinely useful, because they are what decides what gets built next:

• Evaluation questions. Anything on this page that is not specific enough for your sign-off: the supply chain, the licence, the disclosure process, or what is actually implemented today versus what is still on the roadmap.
• Pilots. Standing the gateway and the simulator up against your own environment, and working out what would have to be true before any of it went near production. It is early development software; that conversation starts from there, not around it.
• Design partners. The simulator is being packaged as a certification-readiness kit (#79) — a local rehearsal of the Customer Testing Program’s scenarios, run on your own machines before you book operator time. Institutions that will actually run those scenarios get to shape it.

Two ways to get in touch, both of which already exist:

GitHub DiscussionsPublic, and the better default — someone else is usually asking the same question.

Email the maintainerjoaobuenosi@gmail.com — for anything that should not be public, including pilot and design-partner conversations.

Said plainly, because you would find out anyway: this is not a vendor relationship and there is no support contract behind it. The 72-hour acknowledgement above is a commitment about vulnerability reports; everything else is answered as soon as one maintainer reasonably can. Security problems still go through the disclosure process, never through either channel here.

Licence, data and telemetry

Apache-2.0Permissive, with an explicit patent grant and a warranty disclaimer.

Security policyDisclosure process, supply chain, and the practices this project holds itself to.

Three things worth stating plainly, because evaluators ask:

• No telemetry, no phone-home. The software does not report anything anywhere. Nothing you run reports back to this project, ever.
• The website counts page views, and that is all it does. It uses Vercel Web Analytics: privacy-friendly, cookieless page-view counts. No cookies — none, from anything on this site. No personal data and no IP addresses stored, nothing written to your device by the analytics, and so no consent banner. It is first-party: both the script and the endpoint it reports to are served from this domain under /_vercel/insights/, never a third-party host. The only third-party request this site makes is the OpenSSF badge above, fetched from OpenSSF. Two things stated rather than glossed: the site is hosted by Vercel, which already serves every request to it, so this adds a count and not a new party — and the site does keep two local preferences in your browser (the light/dark theme you picked, and which sidebar sections you left open). They never leave your browser, identify nobody, and are listed by name on About.
• No credentials in the repository, ever — no certificates, no live endpoints, no real routing numbers or institution names. Test fixtures use fictitious identifiers.