Applying for the SignPath Foundation: Free Code Signing for OSS (Part 1: Application)

Until now, "Azure Artifact Signing" (formerly Trusted Signing) has been a strong choice for code signing services on Windows.
However, as of February 2026, the Public Trust for Azure Artifact Signing is limited to "organizations in the US, Canada, EU, and UK" and "individual developers in the US and Canada."
Since it is difficult for individuals or organizations in Japan to utilize this service under the assumption of Public Trust, I considered the SignPath Foundation, which offers free code signing for OSS, as an alternative.

This article outlines the application procedure for the SignPath Foundation (from preparation to submitting the application form).

This article is based on my personal experience of actually applying to the SignPath Foundation while working on code signing for HardwareVisualizer (a hardware monitor software for PCs).

This article focuses on the process "up to the application."
Settings for SignPath after approval and integration with GitHub Actions will be covered in a separate article once the application is approved.

Target Audience

• Those who are releasing (or planning to release) OSS distributions for Windows
• Those who have published source code on platforms like GitHub
• Those who want to try applying to the SignPath Foundation first

Points to Understand Before Applying

Since the SignPath Foundation is a program for "securely signing OSS distributions," the project must meet certain criteria.

Application page: https://signpath.org/apply.html

(Requirements may be updated, so please refer to the latest information on the application page.)

Checklist of minimal points:

• It must be an OSI-approved open source license
• Source code must be in a public repository
• Distributions must be downloadable for free
• Must not contain malicious behavior (no malware, security circumvention, etc.)

Preparation Checklist to Increase Approval Probability

While the application form itself is not difficult, ensuring that the project is easy for reviewers to evaluate will increase your chances of approval.
I performed the following preparations:

• Created a Code Signing Policy https://github.com/shm11C3/HardwareVisualizer/pull/1123
• Created a CODE_OF_CONDUCT https://github.com/shm11C3/HardwareVisualizer/pull/1124

The Code Signing Policy created for this project:

# Code signing policy

This project signs and distributes release artifacts. The signing method differs by platform.

## Windows — SignPath Foundation (pending)

We are applying to the SignPath Foundation program.

Planned statement (required by the program, if approved):
"Free code signing provided by SignPath.io, certificate by SignPath Foundation"

Status: Pending approval.

### What will be signed

- Windows installer packages (e.g. .exe, .msi) published on GitHub Releases.

### Build and signing process

- Artifacts are built from this repository using CI.
- Only CI-built artifacts will be submitted to SignPath for signing.
- The private key is held by SignPath (HSM-backed). This project does not store the private key.

### Team roles (single-maintainer project)

- Authors (commit access, can modify the repository without additional reviews):
  - https://github.com/shm11C3

- Reviewers (review required for changes proposed by non-committers, e.g. pull requests):
  - https://github.com/shm11C3
  - Policy: All external pull requests are reviewed by the maintainer before merge.

- Approvers (approve each signing request):
  - https://github.com/shm11C3
  - Policy: Each signing request requires explicit approval by the maintainer.

## macOS

- Signed with Apple Developer ID and notarized by Apple.

## Linux (currently unsigned)

Status: Not implemented yet.

### What is distributed

- Linux artifacts (e.g. AppImage, .deb, .rpm) published on GitHub Releases.

### Verification

- At this time, Linux artifacts are not cryptographically signed by this project.
- Users should obtain artifacts only from the official GitHub Releases page.

### Future plan (non-binding)

- We may add artifact signing (e.g. Sigstore/cosign or GPG) in a future release.

## Distribution locations

- https://github.com/shm11C3/HardwareVisualizer/releases

## Privacy policy

This program will not transfer any information to other networked systems unless specifically requested by the user.

The contents of the code signing policy are just an example.
Please include the necessary information according to your project's situation and policies.

I created the CODE_OF_CONDUCT to explicitly define the healthy operational policy as an OSS project.
It is based on the Contributor Covenant.

Organizing the Repository Appearance

• Ensure LICENSE (or LICENSE.txt) is located at the root of the repository
• README explains "what this product is" and "where it can be downloaded"
• Build instructions are included in the README (manual or CI is fine)

Being Able to Explain the Provenance of Distributions

Broadly speaking, reviewers want to know the following two points:

1. The binary to be signed originates from "this OSS project"
2. The binary build is reproducible and resistant to tampering

Therefore, having the following ready makes the explanation easier:

• Existence of GitHub Releases (or an official distribution page)
• If building via CI (such as GitHub Actions), the workflow is public

Preparing a Contact Email

Communication after application is primarily via email.

• Use an email address where you can receive replies (personal email is acceptable)
• Ensure you can be reached as the project maintainer

How to Fill Out the Application Form

Application page: https://signpath.org/apply.html

The form wording may change, but essentially it requests the following information:

Project / Repository URL

• Specify the URL of the public GitHub repository
• If there are multiple mirrors, choose the one that acts as the primary source of truth for development

License

• Clearly state the OSI-approved license name (MIT / Apache-2.0 / GPL, etc.)
• It is helpful if you can also point out that a LICENSE file exists

Download / Release URL

• Specify the URL of the distributions that users obtain
  • GitHub Releases
  • Official website download page

Provide a link where it is clear that "distributions can be downloaded for free."

Project description

It can be short, but it is safer to include the following so reviewers do not misunderstand:

• What kind of app/tool it is
• What kind of users use it
• The types of artifacts distributed (exe / msi / zip, etc.)

Example (tone):

This project provides a Windows desktop application for ...
We distribute binaries (exe/msi) via GitHub Releases.
The binaries are built using GitHub Actions from the public repository.

It is safe to write in English (since the review process typically assumes English).
However, as long as the content is understandable at a minimum, being concise is fine.

What Happens After Applying

While the scope of this article is "up to submitting the application," it is reassuring to know the following flow:

• Review of application details (additional questions may arise)
• Once approved, you will receive guidance on how to start using SignPath
• Proceed to project creation in SignPath, GitHub integration, and signing policy design

Next Steps

Once the application is approved, the next steps are "SignPath configuration" and "automating signing with GitHub Actions."

• Follow-up: Automating signing with SignPath + GitHub Actions (to be published after approval)