Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Signed copies in Workloads/ and wsl-comfort/ are stale and no longer verify

Offen
  • Stimmt etwas nicht?
#137 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
powershell
Bereich
ci-cd, release

Rechercherichtung

Start with src/tools/check-signed-drift.ps1 and compare its reported roots with Workloads/, wsl-comfort/, and windows-dev-config/. Run Get-AuthenticodeSignature over the release copies and inspect the existing sign pipeline and the history around #105, #107, and #126. Done means the affected copies are current, retain verifiable signatures, and the validation pass catches signature failures.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

I ran Get-AuthenticodeSignature over the signed release copies, and most of the files under Workloads/ and wsl-comfort/ come back NotSigned. The windows-dev-config/ copies are fine.

Windows 11 Pro 26H2 (build 26300.9550), pwsh 7.6.6, Get-ChildItem <root> -Recurse -Filter *.ps1 | Get-AuthenticodeSignature | Group-Object Status on a git archive:

Root ff7a538 (before #105) 231c59b (current main)
windows-dev-config/ 24 × Valid 32 × Valid
Workloads/ 12 × Valid, 5 × HashMismatch 1 × Valid, 16 × NotSigned, 1 × HashMismatch
wsl-comfort/ 1 × Valid 1 × NotSigned

I think this comes from #105. It marked the signed copies -text, so git checks them out byte for byte. windows-dev-config/ was re-committed as raw signed bytes in #107 right after, but the files under Workloads/ and wsl-comfort/ were committed back when *.ps1 text eol=crlf applied (#26), so their blobs have LF. Before #105, checkout turned that back into the CRLF the files were signed with. Now it doesn't, and the signatures don't match. The ZIP from GitHub has the same bytes.

The only Valid file under Workloads/ is winui/setup.ps1, which is new in #125 and gets signed together with windows-dev-config/ (#126, #130, #132). The other sixteen haven't changed since before #105. winui/install.ps1 is the odd one: it was re-signed, it has CRLF and a signature block, its body matches src/ after normalization, and it still comes back HashMismatch. The five shims that were HashMismatch before #105 looked the same.

I tried putting the CR back. That alone makes 13 of the 17 Valid again, signed by Microsoft Corporation: dotnet, go, java, powershell, rust, sql, the six in _common/ and wsl-comfort/install.ps1. php, python, typescript and winforms become HashMismatch instead, so those four, winui/install.ps1 and wsl-comfort/install.ps1 need to go through signing again. I guess you'd rather just run the sign pipeline over those two roots anyway, but if a PR that puts the CR back in the twelve is useful in the meantime, I have one ready.

The practical effect: the README points people at .\Workloads\<id>\install.ps1 and .\wsl-comfort\install.ps1. When the download and the extraction keep the mark of the web, under RemoteSigned PowerShell refuses .\Workloads\python\install.ps1 with "is not digitally signed". dev-config.ps1, which still verifies, gets the publisher prompt instead, or just runs if Microsoft is already a trusted publisher. From a clone there is no mark of the web, so the same python script passes the RemoteSigned check and can run as an unsigned script. Under AllSigned the copies without a valid signature are refused everywhere.

wsl-comfort/ is also out of date compared to src/. The root comfort-shell-bootstrap.sh still has alias ls="eza --icons" (#79, fixed in src/ by #80), and install.ps1 and readme.md are behind since #120. src/tools/check-signed-drift.ps1 lists all three, plus Workloads/winappcli/* from #106, which has never had a signed release copy committed. The drift check strips the signature block before comparing, so it can't catch the signature problem. A Get-AuthenticodeSignature pass over the three roots in CI would, which I think is what #34 asked about.

If that sign run also commits the raw bytes like #107 and checks the signatures afterwards, it should cover all of this. Happy to help test.

Vorherrschende Sprache
PowerShell
Sterne
2.9k
Forks
202
Ø Merge
18 Std. 49 Min.
Gemergte PRs (30 T.)
24

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus microsoft/WindowsDeveloperConfig

Alle Issues in microsoft/WindowsDeveloperConfig

Ähnliche Issues

Weitere Issues zu DevOps

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.