r/PowerShell

Mean and nasty people are filling the repository with almost-right spelling of the real modules.

Just check the output of this command: Find-Module Microsoft.Graph.auth* There are currently 1 real one and 25 malicious ones

Does anyone knows a github user jshigetomi ? Is he legit or scam? my antivirus software/drivers updater said I need to update my Powershel Core (x64) to 7.6.4. 0 and when i press on the version it send me to jshigetomi's github.

how can i know if it is ok or not? need your help please

I saw a lot of projects have started adopting "Open Source Maintenance Fee" which is described here: https://opensourcemaintenancefee.org which was started by a guy who created WiX.

I'm linking all 4 articles I found from him just for the sake of discussion:

• https://robmensching.com/blog/posts/2025/02/26/introducing-the-open-source-maintenance-fee/
• https://robmensching.com/blog/posts/2025/05/12/open-source-maintenance-fee-two-months-in/
• https://robmensching.com/blog/posts/2026/02/04/osmf-v11/
• https://robmensching.com/blog/posts/2026/07/13/eduforcement/

The general idea on the website is this:

>Open Source Software is free, but maintaining an Open Source Project is far from free. We ask a lot of the maintainers of a project, including:

• Triage issues
• Answer questions
• Keep build scripts working
• Update software dependencies
• Track security reports
• Produce new releases
• Tackle spam in the discussion forums and issue trackers
• Maintain domain name registration
• Renew signing certificates
• And many, many other chores
• Clearly, maintainers are vital to the ongoing success of an Open Source Project. The Open Source Maintenance Fee is a simple and sensible way to pay for the time and effort they spend sustaining a project.

>If you, your organization, or your project meets the minimum annual revenue threshold (typically US$10,000) and depends on projects that require an Open Source Maintenance Fee, paying that fee is how you help sustain the projects you rely on.

I guess he touched a problem that was also many times brought by people maintaining the core of the .NET community such as SixLabors ImageSharp, QuestPDF that basically give users everything and get a "Thank you" back by few, and rest silently just uses it in the background. Both SixLabors and QuestPDF has now implemented MIT for Open Source, and if you make profit you have to pay a fee over certain threshold. I don't want to get into details because it's not about that really, but ImageSharp is quite popular and it's enforcement of licenses is affecting some of the PowerSHell modules.

My point is - open source community is a bit tired.

Lately I saw Polly adopting OSMF:

• https://thepollyproject.org/2026/07/14/polly-osmf-announcement.html

>Polly now participates in the Open Source Maintenance Fee (OSMF). Starting November 16, 2026, companies that earn at least US $20,000 from a product or project that uses Polly will be asked to pay a US $20/month maintenance fee to help fund Polly's ongoing upkeep. The source code stays free and open, and individuals, hobbyists, and organizations below the threshold owe nothing. Read the announcement: Introducing the Open Source Maintenance Fee for Polly · Learn about the OSMF · Become a sponsor

I was thinking how this change applies to us as PowerShell community? How do you feel about it? How do you support the big or small projects that help you out? It doesn't seem it's asking that much as 20$/month for a company is peanuts. I guess it's a bit of a logistics problem to get company into sponsoring someone on GitHub, but it is doable.

Would you use a module if it was OSMF? If not, why not?

PS. For full transparency. I have about 80+ PowerShell modules written over the years and just about 7 or so sponsors (that I am really grateful for). I'm not saying I will adopt the OSMF model, I'm just genuinely asking what you guys think.

Over the last year I built Winzard, a Windows 10/11 post-install and repair tool, entirely in PowerShell 5.1 + WPF — no compiled code, no dependencies, ~19k lines. It's MIT and the repo is at the bottom, but I'd rather this post be about the parts that were genuinely hard, with the actual code, including the ones I got wrong.

1. Two WPF gotchas that cost me hours

.GetNewClosure() on an event handler puts your scriptblock in a new module. $script: inside it then refers to that module's scope, not your script. I had a language picker where you chose English and the app opened in Spanish, silently, because the handler was writing the result into a variable nobody was reading:

# BROKEN: $script:Result is written inside the closure's own module scope
foreach ($label in @('Spanish','English')) {
    $btn = New-Object System.Windows.Controls.Button
    $btn.Content = $label; $btn.Tag = $label
    $btn.Add_Click({ $script:Result = [string]$this.Tag; $dlg.Close() }.GetNewClosure())
    [void]$panel.Children.Add($btn)
}

# WORKS: no closure, so $this is really the sender and $script: is the real scope
foreach ($label in @('Spanish','English')) {
    $btn = New-Object System.Windows.Controls.Button
    $btn.Content = $label; $btn.Tag = $label
    $btn.Add_Click({ $script:Result = [string]$this.Tag; $dlg.Close() })
    [void]$panel.Children.Add($btn)
}

Parameter types are resolved when you call the function, not when you define it. This one failed before the body ran, so the try/catch inside never got a chance:

function Show-Dialog {
    param(
        [string]$Title,
        [System.Windows.Window]$Owner = $null   # <-- "type not found" at call time
    )                                            #     if WPF isn't loaded yet
    try { ... } catch { ... }   # never reached
}

The dialog runs before the main window exists, so on a machine where PresentationFramework hadn't been loaded, calling it threw TypeNotFound and my error handling was useless. Fix: load the assemblies at the top of the script, and leave the parameter untyped if the type might not exist yet.

2. Keeping the UI alive from PowerShell 5.1

Everything heavy runs in a runspace; the UI drains a synchronised queue with a DispatcherTimer to stream the live log into the window:

$queue  = [System.Collections.Queue]::Synchronized((New-Object System.Collections.Queue))
$rs     = [runspacefactory]::CreateRunspace()
$rs.ApartmentState = 'STA'; $rs.Open()
$rs.SessionStateProxy.SetVariable('Queue', $queue)

$ps = [powershell]::Create(); $ps.Runspace = $rs
[void]$ps.AddScript({ param($Queue) ... $Queue.Enqueue("done") })
$handle = $ps.BeginInvoke()

$timer = New-Object System.Windows.Threading.DispatcherTimer
$timer.Interval = [TimeSpan]::FromMilliseconds(120)
$timer.Add_Tick({
    while ($queue.Count -gt 0) { $logBox.AppendText([string]$queue.Dequeue() + "`r`n") }
})
$timer.Start()

The runspace is isolated, so anything it needs — language, admin state, paths — has to be passed in explicitly. A few early bugs came from assuming the worker could see script-scope state it never had.

3. Being honest about what winget actually did

winget upgrade can exit cleanly while the program on disk is byte-identical. Very common with apps that self-update or are running at the time. The only honest check is to re-read the installed version afterwards:

$before = (winget list --id $id -e) -join ' '
winget upgrade --id $id -e --silent --accept-package-agreements | Out-Null
$after  = (winget list --id $id -e) -join ' '
if ($before -eq $after) { Write-Warning "$id reported success but the version did not change" }

Also worth knowing: a corrupted winget source on a freshly installed Windows returns -1978269633 (0x8A15003F). It's retryable — winget source update then try again — not a real failure.

4. The repair suite: no false OKs

17 phases (DISM, SFC, CHKDSK, WMI, network stack, Windows Update, search index, certificates), runnable from a .bat without the GUI, with triage / unattended / quick / dry-run modes.

The design rule was that it must never claim success it can't prove. sfc /scannow prints a friendly summary, but the ground truth is in CBS.log — and reading that log is also the only language-independent way to classify the result. The summary strings change with your Windows display language, so matching on them silently breaks every repair script on a non-English system. That one bites people more than they realise.

Related, and embarrassing: a dry-run mode has to actually be dry. Mine wasn't — phase 16 still wrote an HTML report to disk and opened it in the browser, in four separate code paths. A simulation that writes files isn't a simulation. I only noticed because report windows kept appearing on a machine where "nothing was running".

5. What I got most wrong: elevation

For a long time my launcher self-elevated the moment you opened it. You had to grant admin over the whole program just to browse a list of apps. Convenient while developing, completely wrong to ship.

It now starts as asInvoker and elevates per operation, and it handles the user declining UAC instead of breaking:

try {
    Start-Process powershell.exe -Verb RunAs -ArgumentList $args
    exit 0
} catch {
    # 1223: the user cancelled the UAC prompt. Not an error - carry on unprivileged.
    return $false
}

If you're building anything on Windows that touches the system: start unprivileged and degrade gracefully. The difference in how people trust the tool is bigger than any feature you could add.

---

It's all plain, readable PowerShell, so if any of the above looks wrong to you, you can go and check — and I'd genuinely rather be told.

In fact, that just happened. Someone audited the published version and found that my "no false OKs" claim didn't survive contact with my own code: the ISO verifier reported a missing autounattend.xml through a function that only printed, so it never counted as fatal and the verdict still said "ready to burn" for an image that would never install unattended. Meanwhile all five robocopy calls piped to Out-Null without reading $LASTEXITCODE — and robocopy doesn't use 0=success, 0-7 are success variants and >=8 is the real failure, so even a naive "-ne 0" check would have been wrong. A copy could fail silently, an incomplete ISO got built, and the verifier waved it through.

Also found: -DryRun still ran 'winget source update' because the mode guard came after startup init, so "nothing changes" wasn't true; and the suites parsed arguments as bare ifs with no validation, meaning "/auto /drry" silently ignored the typo and ran a real repair while the user thought they'd asked for a simulation.

All of that is fixed in v1.3.1, each one tested against the specific failure. One of my own fixes was also dead code on the first attempt — "for %%P in (pattern*)" in cmd globs against the current directory, not the target one, so the loop never ran. I only caught it because I tested it instead of assuming.

Development and the destructive testing were done in VMs; the project also ships its own verifier (parsing, ES/EN suite sync, integrity hashes, encoding/BOM rules for 5.1, translation coverage) which I now treat as a hard gate before tagging a release.

Repo: https://github.com/Rebel1487/Winzard

Happy to go deeper on any of it — runspace-based async UIs, CBS parsing, offline DISM servicing, autounattend generation, whatever's useful.

A few days ago I posted here about BOM-less .ps1 files being read as ANSI on Windows PowerShell 5.1. A couple of you pushed back on the parser-test approach and pointed me at the raw-byte check instead, which was right. This is the other half of the same problem: not source files, but output - what happens to CP932 bytes coming back through a pipe.

It matters because agent tooling tends to do this:

subprocess.Popen(args, text=True, encoding="utf-8", errors="replace")

text=True decodes at the pipe level, so by the time anything sees a string the original bytes are gone. On a Japanese-locale box the child process emits CP932, not UTF-8.

Setup. A child writes a fixed 50-byte CP932 sequence to stderr. The parent reads the raw bytes and decodes them two ways. No language pack needed, so the input is identical everywhere. Windows PowerShell 5.1, ACP=932.

decode path	chars	U+FFFD	stray backslash
UTF-8 with replacement	42	29	4
raw bytes then CP932	26	0	-

Three things fell out of it that I did not expect.

1. Not everything becomes U+FFFD. Some of it becomes a backslash.

CP932 trail bytes are 0x40-0x7E and 0x80-0xFC. 0x5C is in that range, and 0x5C is the backslash. A two-byte character whose second byte is 0x5C does not get replaced - it leaves a \ sitting in the string.

Sweeping the whole double-byte space, 50 characters have 0x5C as their trail byte. Four of them are in the 50-byte sample above: 8F5C 975C 8D5C 835C. Those are not obscure code points - they are characters that appear in ordinary words, so this fires constantly rather than occasionally.

That is why this failure so often gets filed as a path bug, a quoting bug, or a shell-escaping bug. The output does not look like an encoding failure. It looks like something ate a directory separator.

2. The whole double-byte space dies.

CP932 double-byte characters enumerated : 9,206
  survive a UTF-8 + replacement decode  : 0
  survive raw bytes + a CP932 decode    : 9,206

Measured per character in isolation. In a real stream a CP932 character followed by other bytes can occasionally form valid UTF-8, so this is not "every byte in every stream" - but as a per-character result it is 0.

3. The replacement output is not even stable across runtimes.

The identical 50 bytes:

.NET Framework 4.8  (Windows PowerShell 5.1)   29 U+FFFD
.NET 8              (PowerShell 7.4)           30 U+FFFD
CPython 3.11                                   30 U+FFFD

There is a known open issue about UTF-8 replacement differing between .NET Framework and .NET Core (dotnet/standard#1679). I am reporting the measurement, not claiming to know the mechanism.

The practical consequence is what changed my mind about errors="replace". It does not merely discard the original bytes - the wreckage it leaves is not consistent either. So you cannot reliably detect "this string was mangled" downstream by counting replacement characters.

Bonus: the tables disagree.

I assumed .NET on Windows would defer to the OS NLS tables and give a different count from .NET on Linux. It does not - .NET carries its own CP932 table and gives 9,206 on both. The split is Python vs .NET, not Windows vs Linux:

table	double-byte chars	trail byte 0x5C
CPython 3.11 cp932	9,604	52
.NET (Windows and Linux)	9,206	50

If you are fixing this on the Python side, Python's table is the more permissive of the two, which is convenient.

The fix is the boring one. Do not let text=True decode at the pipe. Collect raw bytes, then choose the decoder - UTF-8 strict first, fall back to the ANSI code page. errors="replace" should not be the only safety net, because it destroys bytes a fallback could have recovered.

Harness and raw output, MIT: https://github.com/yoggydev/cp932-pipe-probe

It runs in about two seconds and needs no install. The script source is ASCII-only on purpose - a script that measures mojibake should not be able to become a victim of it.

(Drafted with Claude. The measurements are mine, on my own ja-JP box.)

The PowerShell team just announced 13 new security vulnerabilities affecting PowerShell 7.4, 7.5, and 7.6 with severities ranging from 5.9 (Moderate) to 8.8 (High).

This is likely the largest number of security vulnerabilities fixed in any one release in the history of PowerShell.

You can read more about them here: Security Issues - PowerShell/Announcments

PowerShell 7 Version	Affected version	Patched Version
7.6	<7.6.5	7.6.5
7.5	<7.5.10	7.5.10
7.4	<7.4.19	7.4.19

I created a cli tool with rust for mainly windows terminal users (like me), when I try to compare performance with robo copy, I see that mine is mostly faster but after one copy for benchmark, it’s been cached and it’s finishing very fast. So results starting to be useless. If anyone can guide me or give an advice will be much appreciated. Project is open source any contribution also is welcomed.

https://github.com/CanManalp/cpr

This is a Japanese-Windows problem, but the mechanism applies to any DBCS code page.

Everyone knows PowerShell 5.1 reads a BOM-less .ps1 as ANSI (CP932 on a Japanese system), and that the fix is "save it with a UTF-8 BOM". What I did not know was what actually breaks. I always assumed the mojibake was the problem. It is not.

So I measured it: all 545 Japanese characters (hiragana, katakana, kanji, full-width symbols) x all 95 printable ASCII characters (0x20-0x7E). Write the pair as UTF-8, read it back as CP932, and check whether the trailing ASCII character survived.

Results:

• 32 ASCII characters never disappeared
• 63 ASCII characters did, 41.3-46.2% of the time
• Every single one that disappeared was 0x40 or higher. Nothing below 0x40 was ever eaten.

The boundary is exactly 0x40, and the reason is the CP932 trail-byte range:

lead byte:  0x81-0x9F, 0xE0-0xFC
trail byte: 0x40-0x7E, 0x80-0xFC

A Japanese character in UTF-8 is 3 bytes. When its last byte gets misread as a lead byte, the next byte is swallowed as the trail byte - but only if that byte falls inside the trail-byte range, i.e. 0x40 or above.

Which is exactly why this is so hard to diagnose:

"   0x22   never eaten
'   0x27   never eaten
(   0x28   never eaten
;   0x3B   never eaten
\   0x5C   eaten 44.6%
{   0x7B   eaten 41.3%
}   0x7D   eaten 41.3%

Quotes always survive. Your strings still look correctly closed, so you never suspect the encoding. Instead you get "Missing closing '}'" pointing at a completely unrelated line, and you go fix braces that were never wrong.

It is worse for paths. PowerShell uses \ constantly. If a \ sitting right after a Japanese character disappears, the path silently becomes a different path. No error at all - it just looks somewhere else.

With a BOM, across the same 545 characters: 0 broken out of 545. Ran it twice, identical both times.

Practical takeaway: you do not need to memorise the table. Look at the byte value of the ASCII character sitting immediately after Japanese text. 0x40 or above means it can be swallowed.

[edit] The repo this originally pointed at is no longer public. The measurement harness now lives on its own, MIT: https://github.com/yoggydev/cp932-pipe-probe - it carries the same raw-byte BOM check in CI, which is how I ended up chasing this in the first place.

Edit: The developer of this got back to me via email and is working on changing his description. While this doesn't make it 100% safe, it's at least somewhat confidence inspiring. The dev put the telemetry in it to figure out who was installing it because he was noticing it was happening a lot. So lines up with my suspicions.

Wanted to get some thoughts from more experience people here if possible, though I have already reported this module.

I did a stupid and tried to Import-Module Entra in Powershell, what I wanted was Microsoft.Entra, but given it used to be called AzureAD my brain just quick inserted Entra.

I realized shortly after this wasn't the right thing and have removed it, but decided to dig on it some more since it's in PS Gallery afterall.

The author claims it "contains no functional code" but the .ps1 file it runs indeed contains telemetry collection code. Nothing directly malicious as far as I could tell, but wanted to see what others think of this.

Maybe they are just trying to collect info to see how many people mistakenly install this to write something about it?

https://www.powershellgallery.com/packages/Entra/0.3

see screenshot: https://imgur.com/a/JKIwLXd

How I normally get into this weird state is after creating a Win32 Intune package, terminal starts auto completing on every key. Running "clear" fixes it for a short while then it starts happening again. Only "long term" fix is to close that terminal window and open a new one.

Any suggestions?