That

V2 now targets .net8.0 and is using version 12 language features, so it won't be compatible with Framework any more.

However, if you need strong name signing for v1, another option is you could certainly sign it with your own key if that works for you. You can also use sn.exe to exempt specific assemblies from strong name verification, if it's just an application you use internally.

@tig I don't really have a strong opinion one way or the other for v1, personally, since thats in maintenance mode. But for v2 it's useless in every way.

But if you want to do it for v1, it's relatively simple to set up, with the most annoying part just being integrating it into the CI pipeline, but there's plenty of guidance available for that.

And of course then there's the question of the private key and where it is kept and who/what has access to it.

It's not really a security critical thing, though, as it's literally just for generating a unique assembly name for disambiguation. Some projects even distribute the snk file via git because it's mostly just a formality. In fact, even Microsoft suggests doing that, now:

If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.

(From the bottom of https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named#why-strong-name-your-assemblies)

Strong name signing publicly distributed libraries that need to be compatible with pre-5.0 .net core and Framework is a polite policy, but it does have an important caveat: any dependencies of Terminal.Gui would have to be strong name signed as well. It's viral that way, which is the problem @ilCosmico is having with it, since their assembly is strong name signed.

Microsoft has a lot to say about it, and their messaging isn't always consistent, because some of the docs are just re-published Framework docs from long ago, before

Here's a short doc they have on github that links back to a few of the docs on Learn: https://github.com/dotnet/runtime/blob/main/docs/project/strong-name-signing.md

Authenticode signing would be a whooooole different thing and has a price tag as well as actual security ramifications around the private key.

I'm in favor of code signing, and it is one of the various criteria things like Microsoft Endpoint Protection use to make initial assumptions about an application's riskiness, and makes it obvious when something has been tampered with....if you check....

If code signing for releases is something that y'all would be interested in, I might be willing to donate the cost of a code signing certificate, at least for initial registration (usually a year or two), though we'd have to have a talk about it for a lot of reasons.

Enable strong name for Terminal.Gui v1 #3178

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Enable strong name for `Terminal.Gui` v1 #3178