AltTab’s released binaries are Authenticode signed. This document is the project’s public code signing policy, published as a condition of participating in the SignPath Foundation free code signing programme for open source projects.
Free code signing provided by SignPath.io, certificate by SignPath Foundation.
The signature tells you that the binary you downloaded is the exact one produced by this project’s automated build, and that it has not been altered since. It is not a warranty of any kind — AltTab is provided under the MIT License, “as is”.
The publisher shown by Windows is “SignPath Foundation”, not “Lokesh Govindu.” The Foundation holds the certificate on behalf of the open source projects it sponsors, so its name is what appears in the User Account Control prompt and in the file’s Digital Signatures tab. This is expected and is not a sign of tampering.
[!IMPORTANT] While the SignPath Foundation certificate is pending, releases may be signed with an interim self-signed certificate. Windows reports such a signature as invalid, because its chain terminates in a root that nothing trusts, and SmartScreen is unaffected. It is not a substitute for a real signature.
Its one legitimate use is continuity: the certificate thumbprint is published here, so you can confirm that a download carries the same signing identity as previous releases.
| Subject | CN=Lokesh Govindu (self-signed), O=AltTab |
| SHA1 thumbprint | (published here once the interim certificate is in use) |
For actual assurance during this period, use the build provenance check below — it proves the archive came from this repository’s workflow and needs no certificate at all.
Release notes state which of the three states applies, so a release is never presented as trusted when it is not. This section will be removed once SignPath signing is live; the release workflow prefers SignPath automatically whenever its secrets are configured.
| Artifact | Signed | Notes |
|---|---|---|
AltTab.exe (Release) |
Yes | The build with file logging enabled |
AltTab.exe (ReleaseNoLogger) |
Yes | The default download, logging compiled out |
AltTab_<version>_*_x64.7z |
No | Authenticode signs PE files, not archives |
AltTab.chm, ReadMe.txt, ReleaseNotes.txt |
No | Documentation, not executable code |
The executables are signed before they are packaged, so the .exe inside every
release archive carries the signature. Archive integrity is covered separately by
the SHA256SUMS.txt published with each release.
Released binaries are built only by
.github/workflows/release.yml running on GitHub
Actions, from the tagged source in this repository. No binary built on a
maintainer’s machine is ever signed or published.
Two consequences of that policy are worth calling out:
log4cpp.lib, the build compiles it from
libraries/log4cpp-1.1.4.tar.gz via
Scripts/BuildLog4cpp.ps1, which verifies the
tarball’s SHA256 before extracting it. Nothing opaque enters the signed binary.Scripts/VersionInfo.txt.SignPath requires named roles and a human approval for every signing request.
| Role | Held by |
|---|---|
| Author — submits a signing request by tagging a release | Lokesh Govindu (@lokeshgovindu) |
| Reviewer — confirms the request corresponds to a reviewed commit | Lokesh Govindu |
| Approver — releases the signature | Lokesh Govindu |
AltTab is currently maintained by a single developer, so these roles are held by one person; contributions arrive as pull requests that the maintainer reviews before merging. This table must be revised if additional maintainers gain release rights.
Every release is approved manually in the SignPath web console. Signing is never automatic: a tag push builds the binaries and submits the request, and nothing is signed until a human approves it.
Accounts with release or signing rights have multi-factor authentication enabled on both GitHub and SignPath.
The full policy is in PRIVACY.md. In short:
AltTab contains no analytics, telemetry or crash reporting, and sends no usage data
anywhere. It makes exactly one network request — downloading a version file from
SourceForge to check for updates — transmitting no information of its own. That
check is on by default at startup and can be set to Daily, Weekly or Never;
Never stops all network activity. Settings, a last-check timestamp, and (in the
optional logging build) log files are written locally and never transmitted. AltTab
installs nothing system-wide, so deleting its folder removes it completely.
Three independent checks are available, in increasing strength.
Compare against SHA256SUMS.txt from the same release:
certutil -hashfile AltTab_2026.2.0.0_x64.7z SHA256
Every release archive carries a GitHub build attestation: a signed statement that this exact file was produced by this repository’s release workflow, at a specific commit. Verify it with the GitHub CLI:
gh attestation verify AltTab_2026.2.0.0_x64.7z --repo lokeshgovindu/AltTab
This is stronger than a checksum, because a checksum only proves the file matches a number published on the same page; the attestation ties the file to the build that made it. It is independent of Authenticode and needs no certificate — but Windows does not consult it, so it has no effect on SmartScreen.
Inspect the extracted executable’s signature. The simplest check is to right-click
AltTab.exe → Properties → Digital Signatures; the signer should be the
SignPath Foundation.
To verify from a command line, using the Windows SDK’s signtool:
signtool verify /pa /v AltTab.exe
A valid signature exits with code 0 and prints the signing certificate’s subject.
If you find a binary published under this project’s name that fails signature verification, or a signed release you cannot reproduce from source, please open an issue at https://github.com/lokeshgovindu/AltTab/issues. For anything you believe is a key or account compromise, contact the maintainer privately rather than filing a public issue, and notify SignPath.
The signing step activates once these are configured on the repository. Until then the release workflow still runs and produces an unsigned draft release, with a warning in the release notes.
Repository secrets:
| Secret | Value |
|---|---|
SIGNPATH_API_TOKEN |
API token issued by SignPath |
SIGNPATH_ORGANIZATION_ID |
SignPath organization ID |
SELFSIGN_PFX_BASE64 |
Interim self-signed .pfx, base64 encoded (optional) |
SELFSIGN_PFX_PASSWORD |
Password for that .pfx (optional) |
The workflow resolves one of three signing modes per release, preferring the real
certificate: signpath when its secrets are set, otherwise selfsign when the
interim ones are, otherwise none. Rehearsal runs never sign. Delete the
SELFSIGN_* secrets once SignPath is live — though they are ignored anyway while
SignPath is configured.
Generate the interim certificate with:
python -m pip install -r Scripts/requirements-dev.txt
python Scripts/NewSigningCert.py --password "<a strong password>"
That prints the base64 blob and the thumbprint. Publish the thumbprint in the table
above and set it as a SELFSIGN_THUMBPRINT repository variable, which makes the
build refuse to publish binaries signed by any other certificate. Keep the .pfx
out of the repository.
Repository variables (optional — defaults in parentheses):
| Variable | Purpose |
|---|---|
SIGNPATH_PROJECT_SLUG |
SignPath project slug (AltTab) |
SIGNPATH_POLICY_SLUG |
Signing policy slug (release-signing) |
SIGNPATH_ARTIFACT_CONFIG_SLUG |
Artifact configuration slug, if the project defines more than one |
RELEASE_RUNNER |
Runner image override, should windows-latest ever lag behind the v145 toolset (windows-latest) |
The release workflow uploads a single artifact containing both executables, so one
approval covers the whole release. The SignPath artifact configuration therefore
needs to declare both Release/AltTab.exe and ReleaseNoLogger/AltTab.exe.
To cut a release:
# 1. Make sure Scripts/VersionInfo.txt holds the version you intend to ship.
# 2. Optional but recommended -- rehearse it. Pushing a release/** branch runs the
# whole pipeline without creating a release or requesting a signature. Download
# the run's artifacts to check the archives before committing to a tag.
git switch -c release/2026.2
git push -u origin release/2026.2
# 3. Tag and push; the workflow does the rest.
git tag 2026.2.0.0
git push origin 2026.2.0.0
# 4. Approve the signing request in the SignPath console.
# 5. Review the draft release on GitHub and publish it.
Rehearsal runs never submit signing requests: signing is gated on the ref being a tag, so a practice run cannot consume one of the manual approvals.