Enable strong name for Terminal.Gui v1

[ilCosmico]

I need to use this library in my project which must have all the assemblies strong-named.

Could you consider signing the assembly with a public sign, please?

[tig]

Absolutely. Can you provide more details on how this is done?

[BDisp]

See https://learn.microsoft.com/en-us/dotnet/standard/assembly/sign-strong-name.

[dodexahedron]

It's not relevant in .net since version 5. Strong name signatures are not checked. As this library does not support .net Framework, there's no point in this.

See this and plenty of other documentation on the subject, for modern .net:
https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/strong-name-signing-exceptions

What is the reason behind that policy?

If you need actual code signing, that's a different thing all together.

[ilCosmico]

@dodexahedron I am using this library in my project which targets net472/net6/net7/net8 and I have observed that it also supports .NET Framework.

Additionally, since all my assemblies are strongly named, I need this library to be strongly named too.

[BDisp]

Only on the v1 it's possible because it uses .net Framework.

[dodexahedron]

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.

[ilCosmico]

@dodexahedron, I understand your concerns about strong-name signing for the Terminal.Gui library, especially for v2 which targets .NET 8.0. However, strong-name signing is still considered a good practice for .NET Framework projects, and there are several reasons why it is important.

• Identity and security: Strong-name signing allows you to uniquely identify an assembly and verify that it has not been tampered with. This is important for security, as it helps to prevent people from substituting malicious code for the original assembly.

• Interoperability: Strong-name signing is also required for assemblies to be used in the Global Assembly Cache (GAC), which is a shared location where assemblies can be installed for use by multiple applications. If an assembly is not strong-named, it cannot be installed in the GAC.

• Compatibility: Strong-name signing can also help to ensure compatibility between assemblies. For example, if an assembly is strong-named, it will only be loaded by applications that have been compiled with the same strong-name key. This can help to prevent compatibility problems that can arise when using assemblies from different sources.

In addition to these benefits, strong-name signing is also a relatively simple process as explained in the link provided by @BDisp.

Last but not least, considering that @tig has already expressed their willingness to make this change, it is surprising that you are so opposed to it.

[BDisp]

@ilCosmico I think @tig will consider this only for v1, of course, but you need be realize that v1 won't have news feature nor regular fixes which I think you already have knowledge.

[ilCosmico]

@BDisp yes, sure. I'm aware of this, but for the use I need v1 is perfect!

[ilCosmico]

@tig, any ETA on when this will be available for v1, please?

[tig]

@tig, any ETA on when this will be available for v1, please?

If you or someone else would like to submit a PR that would be awesome. I'll merge it as soon as it's ready.

[dodexahedron]

Oh don't get me wrong - I think it'd be a nice thing to do for V1, since it happens to be compatible with Framework.

But nothing about .net8 (or any .net from 5 forward) supports it or even checks it, so it'd be pointless for V2. 🤷‍♂️

[ilCosmico]

PR #3191 created.

BTW I see that this library depends on NStack one, so I think that it must be strongly named too.

[BDisp]

PR #3191 created.

It's so rewarding to see a user who needs to fix a bug or needs a new feature create their own fixes. Of course, this only applies to those who really know how or want to try to do it. Thanks.

BTW I see that this library depends on NStack one, so I think that it must be strongly named too.

The NStack library is only needed for the v1. On the v2 we now only use string and the System.Text.Rune. The better way is you also create a PR there with the feature. Then you can publish locally and test it against the Terminal.Gui. Use the locally published library instead of the nuget package and verify it's working properly. Good luck.

[ilCosmico]

The NStack library is only needed for the v1. On the v2 we now only use string and the System.Text.Rune. The better way is you also create a PR there with the feature. Then you can publish locally and test it against the Terminal.Gui. Use the locally published library instead of the nuget package and verify it's working properly. Good luck.

Done. PR #91.

[dodexahedron]

PR #3191 created.

BTW I see that this library depends on NStack one, so I think that it must be strongly named too.

Thanks for providing that. :)