git-wt.exe is identified as a Trojan by Windows Defender Antivirus

[bemnlam]

Description

Windows Defender Antivirus identifies the exe as Trojan Trojan:Win32/Wacatac.B!ml

Context

Use winget install max-sixty.worktrunk for installation. Fails every time. Turns out it's Windows Defender blocks it.

https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?name=Trojan%3AWin32%2FWacatac.B!ml&threatid=2147735505

[worktrunk-bot]

Thanks for the detailed report, @bemnlam — screenshot and threat link both help.

This is a false positive, not actual malware. The !ml suffix on Trojan:Win32/Wacatac.B!ml marks it as a machine-learning/heuristic detection rather than a signature match, and Wacatac is one of Microsoft's generic family names that routinely misfires on small, unsigned native executables. Worktrunk's Windows binary (git-wt.exe) is exactly that shape: it's built by cargo-dist as a plain x86_64-pc-windows-msvc executable with no Authenticode code-signing step, so Defender's cloud heuristic has nothing signed to trust.

Two things you can do right now:

1. Report the false positive to Microsoft. Submitting the file at the Windows Defender submission portal (as "I believe this file is safe") gets it re-analyzed and the cloud definition corrected, usually within a day or two — which fixes it for every Worktrunk user on Defender, not just your machine.
2. Install from source instead of the pre-built artifact. cargo install worktrunk compiles the binary locally with your own toolchain rather than downloading the flagged artifact, which typically sidesteps this class of heuristic. (It needs a Rust toolchain installed.)

The durable fix on our side would be Authenticode-signing the Windows release binaries in the pipeline, but that's a certificate/cost decision — I'll leave it for a maintainer to weigh in on and prioritize.

Why this fires — sources

• Windows target and lack of any signing step: dist-workspace.toml (targets = [… "x86_64-pc-windows-msvc"], no signing config) and release.yaml (build → GitHub Release → winget; no signtool/Authenticode step).
• The Windows binary is named git-wt.exe — the release enables the git-wt feature (features = ["git-wt"] in dist-workspace.toml), matching the title of this issue.
• !ml = ML/heuristic cloud detection; Wacatac is a generic detection family — see Microsoft's own threat description you linked.

[max-sixty]

ok but @worktrunk-bot how can we not have this happen?

[worktrunk-bot]

Short version: the only durable fix is Authenticode code-signing the Windows binary. A valid signature is what stops Defender's ML heuristic from firing on a small unsigned native exe — everything else (submitting false positives, cargo install) is a workaround that treats symptoms. The real decision is which signing path, and it's a cost/identity tradeoff, so here are the concrete options:

1. SignPath Foundation — free, and the best fit for us. SignPath's Foundation program gives OSS projects a free code-signing certificate and CI signing. Eligibility (terms): OSI-approved license, no malware, active maintenance/existing releases, and a published code-signing policy page on the project site (they also want per-release approval + MFA on committers). No stars/traffic threshold. Downside: cargo-dist doesn't support SignPath natively — we'd add a signtool/SignPath step to release.yaml, which is fine since we already run custom CI jobs (allow-dirty = ["ci"]).

2. Azure Artifact Signing (formerly Trusted Signing) — cheap (~$10/mo) but likely blocked for us. Their identity verification generally requires an organization that's been established 3+ years; individual/young-org accounts get rejected. cargo-dist also doesn't support it yet.

3. SSL.com eSigner — the only provider cargo-dist supports out of the box (docs: set ssldotcom-windows-sign = "prod" + four GitHub secrets). Cleanest integration, but it's a paid certificate + subscription.

4. Traditional OV/EV cert — EV gives instant SmartScreen reputation but needs a hardware token (awkward in CI); OV is cheaper but reputation builds over time. For the Defender AV heuristic specifically (the Wacatac.B!ml here), any valid signature is usually enough — the SmartScreen reputation nuance mostly matters for the "unrecognized app" download prompt, a separate thing.

Recommendation: go with SignPath Foundation (#1) — free, OSS-native, and it directly kills this false-positive class. The two costs are the custom CI step and publishing a short code-signing-policy page (a docs addition).

Two caveats to set expectations: signing raises the bar but Defender's ML heuristic can still occasionally misfire until the signed binary accrues reputation, and it only covers the winget/GitHub-Release artifact — cargo install builds are already local and unaffected.

If you want to pick a provider, I can open a PR wiring it into release.yaml and add the code-signing-policy page — just say which one.

_{Sources: SignPath Foundation · SignPath OSS terms · cargo-dist Windows signing docs · cargo-dist Azure Artifact Signing request #2395}

[max-sixty]

ok please do what you can re #1 and let me know what I need to do

[worktrunk-bot]

On it. I've opened #3366 with the code-signing policy page — publishing one is a hard eligibility requirement for SignPath Foundation, so it's the piece that has to land first before the application will go anywhere. Once it merges and deploys, the policy lives at https://worktrunk.dev/code-signing/.

I stopped there deliberately: the actual release.yaml signing step needs an organization-id, project-slug, and signing-policy-slug that only exist after SignPath approves the project, and I don't want to wire a checksum-sensitive step into the live release pipeline that I can't run end-to-end. So here's the split.

What you need to do

1. Apply at signpath.org/apply. Point the "code signing policy" field at https://worktrunk.dev/code-signing/ (merge docs(code-signing): add SignPath Foundation code-signing policy page #3366 first so the URL resolves). They verify the binary is built from this public repo — no personal ID required.
2. After approval, in the SignPath console:
   • Note your Organization ID.
   • Create a Project (suggest slug worktrunk), an Artifact Configuration (describes the release .zip → sign git-wt.exe inside it), and a Signing Policy (suggest slug release-signing).
   • Create a CI (GitHub Actions) connector API token.
3. In this repo's Settings → Secrets and variables → Actions:
   • Secret: SIGNPATH_API_TOKEN = the token from step 2.
   • Variables: SIGNPATH_ORGANIZATION_ID, SIGNPATH_PROJECT_SLUG, SIGNPATH_SIGNING_POLICY_SLUG.
4. Confirm the policy roster (currently just you as Author/Reviewer/Approver) and that MFA is on for your GitHub + SignPath accounts — both are program requirements.

What I'll do next

Once those four vars/secret exist, ping me and I'll open the follow-up PR wiring the signing job into release.yaml, gated on vars.SIGNPATH_ORGANIZATION_ID so it's inert until configured and can't break a release mid-setup.

Proposed job shape (verified against the SignPath action, for the follow-up)

Uses SignPath/github-action-submit-signing-request@v2. The wrinkle is cargo-dist: it writes a per-artifact .sha256 in the local build job next to the .zip, so signing has to happen before host uploads, and the signed zip's checksum must be regenerated. Sketch:

sign-windows:
  needs: [plan, build-local-artifacts]
  if: ${{ needs.plan.outputs.publishing == 'true' && vars.SIGNPATH_ORGANIZATION_ID != '' }}
  runs-on: ubuntu-24.04
  steps:
    - uses: actions/download-artifact@v8   # the windows build-local artifact
      with: { pattern: 'artifacts-build-local-*windows*', path: dist }
    - id: sign
      uses: SignPath/github-action-submit-signing-request@v2
      with:
        api-token: ${{ secrets.SIGNPATH_API_TOKEN }}
        organization-id: ${{ vars.SIGNPATH_ORGANIZATION_ID }}
        project-slug: ${{ vars.SIGNPATH_PROJECT_SLUG }}
        signing-policy-slug: ${{ vars.SIGNPATH_SIGNING_POLICY_SLUG }}
        github-artifact-id: <the uploaded windows zip artifact id>
        wait-for-completion: true
        output-artifact-directory: signed
    # then: regenerate the .sha256 for the signed zip and re-upload the
    # artifact so `host` publishes the signed archive + correct checksum.

The github-artifact-id needs the upload step's outputs.artifact-id; the exact Artifact Configuration (whether SignPath signs the exe inside the zip and repackages, vs. we extract/sign/re-zip ourselves) is the one detail I'll nail down against your approved SignPath project before shipping this.

Same two caveats as before still hold: signing kills the false-positive class but Defender's ML can occasionally still misfire until the signed binary earns reputation, and this only covers the winget / GitHub-Release artifact — cargo install is already local and unaffected.

[max-sixty]

OK, I merged that and applied, let's check back when I hear back

[max-sixty]

Status update: the code signing policy page shipped in v0.67.0, and the SignPath OSS application for Worktrunk is submitted — SignPath confirmed receipt and is reviewing the project. If approved, the setup proceeds through a test certificate and origin verification before the production certificate is issued for release builds. This issue stays open until signed Windows binaries ship.

This was written by Claude Code on behalf of max