Application status changes with our workload. Check ossign.org to see whether applications are currently open.
Qualification Criteria
Public Availability
Your project must be publicly accessible on Github. We do have plans to support other platforms in the future, but for now, Github is required.
While we require the project and signing to happen on Github, you can of course use another platform for development and collaboration as long as you mirror that progress to your Github repository.
Single Project
Your application is always for a single Github project, or a single primary Github project with one or two clearly related dependencies that are essential for the functionality of the primary project.
Open Source License
Your project must be licensed under an OSI-approved open source license and be publicly available for anyone to read on Github.
This is partially for the integrity of the signing process, anyone should be able to see and verify the entire source code that corresponds to the signed binaries (with a few minor exceptions for trusted, verifiable plugins or dependencies used during the process).
It is also because our efforts are focused on providing the service to developers that make a meaningful contribution to the open source community. Projects that do not meet this criterion may not be eligible for signing.
Active Project with History
Our volunteered time is limited, and we want to ensure we are spending it where it makes the most impact on the community.
Your account, project and/or organization must have a minimum of 6 months of regular activity prior to applying for signing. This requirement is absolute and non-negotiable. A fork of an existing project must generally also meet this requirement independently of the original project's history, but exceptions can be considered if the forking user or organization has a demonstrable track record of contributions to the open source community, and the original project is considered abandoned.
Your project must have a consistent history of contributions and activity, demonstrating ongoing development and maintenance.
Your project should be able to show a clear impact on the community with an active userbase (stars, issues, pull requests, discussions, contributions, downloads)
LLM-generated Content
We do not automatically exclude LLM-generated content from our signing process, but it will be evaluated on a case-by-case basis to ensure it meets our standards for quality, originality, and contribution to the open source community. The project author should be able to demonstrate a clear understanding of the generated content and how it works.
Public Automation
Your project should already have a CI pipeline in place, or a clear set of automated steps for building and testing the project.
This should include automated security testing like vulnerability scanning and dependency checks.
Commercial Projects
The primary focus of OSSign is code signing for projects and developers that volunteer their time and create free and open-source software for other users. We can consider signing projects of a commercial nature with an open source license, but there are additional requirements. Contact us to learn more.
Open-source projects with a split license model can be approved, but we generally encourage projects we sign for to not have basic security functionality like SSO, Encryption or other similar features hidden behind that commercial license. We strongly believe that secure authentication is a fundamental requirement these days and should be available to anyone.
Political or Controversial Projects
We are not able to sign software or other tools that have a clear political or controversial purpose. This includes, but is not limited to:
- Tools used primarily for offensive security research or unauthorized access to computer systems or networks.
- Tools used for piracy and piracy-adjacent activities.
- Tools with a clear party-political, partial-political or controversial purposes.
- Tools that are intended to deceive or defraud users.
- Tools that promote hate speech or discrimination.
- Tools that violate privacy or facilitate unauthorized data collection.
- Tools that otherwise violate laws, conventions, export/import controls, sanctions or other regulatory requirements.
Types of Software
We do not have a blanket restriction on signing certain types of software, but during the signing process we will generally evaluate project contents and look for the following:
- Presence of potentially harmful or malicious code.
- The presence of testing certificates, custom private CAs installed into root trust stores.
- The presence of obfuscated or otherwise hard-to-audit code.
- The presence of code that attempts to bypass security mechanisms or restrictions.
- The presence of code that can be used on end-user system for malicious purposes such as, but not limited to, privilege escalation, unauthorized remote code execution, unauthorized remote access, data exfiltration or tampering.
Risk evaluation
During the initial review process and subsequent human reviews, we will assess potential risks with all projects. You may be asked to provide additional information or clarification regarding your project's contents and intended use, and you may be asked to change certain functions or features to mitigate identified risks.
Projects that are deemed too high-risk may be rejected, and previously signed projects may have their signatures revoked if new significant risks are identified.
Staying Signed
You do not need to reapply after a year, but signed projects remain subject to the same criteria. We may contact you from time to time to check on the status of your project and make sure it is still in compliance.
Archived projects are considered abandoned and will lose their ability to sign new files.
The Signing Process
These follow from how signing works and apply to every signed release:
- Everything is signed through your OSSign repository. Signed files are built by its workflow from the commit the review approved, never uploaded from elsewhere.
- Workflow changes go through a pull request. Changes to the signing workflow are reviewed by the OSSign team before they are merged.
- Every release is reviewed. Changes since the last approved commit are reviewed before the signing job is released, and the review report is published with the release.
Certificate and Identity
Signing is done with OSSign's certificate, which already has an established reputation. Your real name does not have to appear anywhere on the certificate, signature or binary if you do not want it to, but we will always include the project name and link wherever possible.
Dedicated certificates are not offered as a rule. For a large project that has used OSSign for a while we may consider one if this is necessary; for smaller projects our shared certificate is usually the better choice.
Extended Validation (EV) certificates
We will generally use an OV certificate for the majority of our signing process. Since a few years back, Microsoft made changes to its trust process regarding EV certificates meaning that they no longer provide any additional trust benefits over OV certificates when it comes to Smart Screen warnings, antivirus/antimalware checks or verifications.
Kernel-level drivers
The process for signing kernel-level drivers is more stringent than for regular applications due to the elevated privileges these drivers have within the operating system. These drivers must meet stricter security and verification requirements to ensure system stability and security.
Attestation Signing
Attestation signing is the lowest level of kernel-level driver signing, providing basic verification that the driver comes from a trusted source without requiring extensive testing or certification. These drivers are generally accepted on Windows 10 1809 and later and Windows 11. They are suitable for most open-source projects that do not require the additional validation provided by WHQL certification, and do not need to be run on Windows Server operating systems.
WHQL Certification
WHQL (Windows Hardware Quality Labs) certification is a higher level of kernel-level driver signing that requires extensive testing and validation before submission to Microsoft. Drivers with WHQL certification are generally accepted on all supported Windows versions, including Windows Server operating systems, and provide a higher level of trust and compatibility assurance. This level of signing is typically reserved for projects that require broad enterprise deployment or have specific compliance requirements.
In cases where WHQL certification testing is required, we will usually require that this is done in the customers environment due to the large amount of work involved.