Two eligibility questions before applying, because the answers decide whether it is worth building the
release pipeline the Foundation requires. I have read the terms and believe the project qualifies on
licence, maintenance and released-artifact grounds — these are the two points the terms do not cover.
The project: MultiSeat — MIT, public, four
releases. It runs multiple simultaneous game-streaming sessions on one Windows host.
1. Does SignPath Foundation sign Windows driver packages at all?
The terms cover applications but say nothing about drivers either way. The artifact in question is a
user-mode UMDF/IddCx display driver — a catalog (.cat) plus a user-mode DLL. It is not a
kernel-mode driver, so it does not need Microsoft attestation or an EV certificate; an Authenticode
signature chaining to a publicly trusted root is sufficient for it to install.
If driver packages are out of scope for the Foundation, that is a completely reasonable answer and I
would rather know now.
2. May a project sign a driver that originates upstream, rather than in its own repository?
The driver is from an MIT-licensed upstream OSS project which my project would build and redistribute
as a component. The terms say I may include unsigned binaries of upstream OSS projects in signed
packages, and that I should ask upstream maintainers to obtain signatures separately.
Upstream has its own SignPath sponsorship for a different project, and understands that it does not
extend to a driver distributed independently of that project. So "ask upstream" appears to be a dead
end here, which is why I am asking whether signing it as a component of my release is acceptable, or
whether the same reasoning would apply.
Context, so the questions are not abstract
From the terms, I understand that the certificate is issued to SignPath Foundation rather than to the
project and that SignPath Foundation appears as the publisher; that every release needs manual
approval; and that binary artifacts must be built from source in a verifiable way.
That last one is work I do not yet have — the project has no CI at present, and signing would mean
building a proper release pipeline first. I am willing to do that, but only if the answers above make
it worthwhile, hence asking before rather than after.
On the proprietary-component condition: the project bundles nothing proprietary. Its prerequisite
installer downloads third-party dependencies at install time and none of them are committed to the
repository.
Thanks for running the Foundation — and if a GitHub issue is the wrong channel for this, tell me where
to send it and I will move it.
Two eligibility questions before applying, because the answers decide whether it is worth building the
release pipeline the Foundation requires. I have read the terms and believe the project qualifies on
licence, maintenance and released-artifact grounds — these are the two points the terms do not cover.
The project: MultiSeat — MIT, public, four
releases. It runs multiple simultaneous game-streaming sessions on one Windows host.
1. Does SignPath Foundation sign Windows driver packages at all?
The terms cover applications but say nothing about drivers either way. The artifact in question is a
user-mode UMDF/IddCx display driver — a catalog (
.cat) plus a user-mode DLL. It is not akernel-mode driver, so it does not need Microsoft attestation or an EV certificate; an Authenticode
signature chaining to a publicly trusted root is sufficient for it to install.
If driver packages are out of scope for the Foundation, that is a completely reasonable answer and I
would rather know now.
2. May a project sign a driver that originates upstream, rather than in its own repository?
The driver is from an MIT-licensed upstream OSS project which my project would build and redistribute
as a component. The terms say I may include unsigned binaries of upstream OSS projects in signed
packages, and that I should ask upstream maintainers to obtain signatures separately.
Upstream has its own SignPath sponsorship for a different project, and understands that it does not
extend to a driver distributed independently of that project. So "ask upstream" appears to be a dead
end here, which is why I am asking whether signing it as a component of my release is acceptable, or
whether the same reasoning would apply.
Context, so the questions are not abstract
From the terms, I understand that the certificate is issued to SignPath Foundation rather than to the
project and that SignPath Foundation appears as the publisher; that every release needs manual
approval; and that binary artifacts must be built from source in a verifiable way.
That last one is work I do not yet have — the project has no CI at present, and signing would mean
building a proper release pipeline first. I am willing to do that, but only if the answers above make
it worthwhile, hence asking before rather than after.
On the proprietary-component condition: the project bundles nothing proprietary. Its prerequisite
installer downloads third-party dependencies at install time and none of them are committed to the
repository.
Thanks for running the Foundation — and if a GitHub issue is the wrong channel for this, tell me where
to send it and I will move it.