Sign binaries with a Code Signing Certificate

[fredrikeriksson]

Analyzers usually get's blocked by AppLocker and to allow these the run admins need to add AppLocker whitelisting rules, while path is an option trusting the publisher of signed binaries is generally prefered.
Do note that I see that you recently did implement Strong Name Signing, this is not the same thing :)

Could this be considered at all?
https://signpath.org/ have a free OSS offering that you probably could use, don't have any personal experience with them though.

[thomhurst]

Hmm.. This isn't something I've done before so don't know too much about it.

So currently your IDE experience is lacking because the Analyzers aren't running? (I assume that means source generators could be blocked too which would block TUnit entirely.)

And from what you're saying, having this signing would stop them being blocked?

So does the .nupkg get signed?

[rassilon]

I think he means in the Authenticode .dll/.exe signing sense, since I don't think Visual Studio runs the analyzers from within the .nupkg?
Zip containers do support signing in various forms, depending on the content contained. I don't know if, for instance, signed Office docs use the same signing approach as, say, Java JAR files. Both of which, of course, are Zip containers of the actual data.

[viceroypenguin]

I think he means in the Authenticode .dll/.exe signing sense, since I don't think Visual Studio runs the analyzers from within the .nupkg?

Yes; VS absolutely runs analyzers from within the .nupkg. Or rather, VS calls Roslyn for live analysis, and Roslyn loads analyzers from the .nupkg. Otherwise, half the diagnostics you currently receive in VS would not function, since they are pulled from various msft distributed nuget packages.

[thomhurst]

Isn't a nupkg basically a glorified zip file?

What would I need to actually do for this? This is foreign territory for me

[fredrikeriksson]

Firstly I'm sorry I missed your initial response, and I also realize the openener might have been a bit thin so to give you some more background:
AppLocker is a feature in Windows which pretty much is a Default Deny mechanism for executables, binaries and scripts and requires rules to Allow either by Publisher (Signing Certificate), File/Path, File hashes.
Usually there is some basic rules like "trust everything Microsoft" and then you adjust for further needs, preferably allowing publishers, paths in user non writeable folders, filehash and lastly paths in user writable folders (as %TEMP% for example), in that order.

Although a "bad" allow rule can sometimes be preferable to users with admin elevating Visual Studio to circumvent AppLocker as that would mean any child processess also runs elevated which then could be really bad if some nupkg is infected.

Roslyn loads Analyzers into a temporary folder like C:\USERS\USER01\APPDATA\LOCAL\TEMP\ROSLYN\ANALYZERASSEMBLYLOADER\ (actually more subfolders but for brevity sake).
And as this is denied by default an allow rule you would ideally trust the publisher of the package in question but that requires the binaries to be signed with a Code Signing Certificate.

The next best thing is to go for a path based rule like %OSDRIVE%\USERS\*\APPDATA\LOCAL\TEMP\ROSLYN\ANALYZERASSEMBLYLOADER\*.dll.

Do note it's a user writeable path but as I mentioned before this can still be better than not allowing.

Isn't a nupkg basically a glorified zip file?

What would I need to actually do for this? This is foreign territory for me

Yes you are correct, but it's not the nupkg that's signed but rather the packaged binaries/executables/scripts.

I guess you could sign the nupkg but that would only prove that the nupkg has a proven publisher and has not been tampered with.
Similar concepts regarding security but enforced on slightly different layers, nupkg signature validation would be suitable in a CI/CD pipeline for example.

What would you need to do?
As I mention in the first post https://signpath.org/ is an option for OSS.
It would be a good step to establish trust of your package, at the downside it can come with some burden.
Albeit Sign Path takes away a large portion of that, maintaining the code signing by yourself is usually alot more cumbersome.
Also you add a third party in the trust chain, maybe not a big deal but still something to be aware of.

Wether it's worth it or not is in the end up to you as a non-profit OSS maintainer :)