Strong name the releases please

[jherby2k]

I see #308 was closed with a suggestion to use StrongNamer. Which is fine, but...

Microsoft's new library guidance (out yesterday!) specifically recommends you strong-name sign your open-source libraries, and just provide the private key in the repo: https://docs.microsoft.com/en-ca/dotnet/standard/library-guidance/strong-naming.

Its worth mentioning that of the dozen-odd nuget packages I'm referencing, this is the only one that isn't signed.

[antonfirsov]

I'm not saying we are happy about this, but that Microsoft recommendation is a game changer. We should definitely do this now, maybe for RC1 already.

[JimBobSquarePants]

Yeah, the tide has definitely turned. RC1 shall be strong named.

[etomm]

Why you should not be happy I really don't understand. StrongNaming is a safety mechanism and it's a must have. I am waiting for it too.

[JimBobSquarePants]

That’s utter bollocks. Strong naming should never be used for security. MS literally warn you not to in their documentation.

[astrowalker]

@JimBobSquarePants , could you please pass a link and a quote. Thank you in advance.

[JimBobSquarePants]

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/strong-named-assemblies

Do not rely on strong names for security. They provide a unique identity only.

[etomm]

@JimBobSquarePants I didn't mean safety in the mean of security. I was merely meaning exactly what Microsoft means when they speak about unique identity. Maybe I wrote it too short :)

[jherby2k]

There is no need to argue about merits -they’ve agreed to sign it. Let them focus on getting RC1 out the door!

[brutaldev]

In the meantime you can use my Strong-Name Signer tool to do it for you: https://github.com/brutaldev/StrongNameSigner/

[jakubmisek]

In the meantime you can use my Strong-Name Signer tool to do it for you: https://github.com/brutaldev/StrongNameSigner/

it works for executable projects right? not the libraries

[brutaldev]

@jakubmisek It works against compiled assemblies (managed executables are also assemblies). You can point it at your "packages" directory and let it sign anything that isn't already signed as well as fixing references to any unsigned dependencies.

[jakubmisek]

@brutaldev right, so I cannot provide a library depending on ImageSharp because I would have to instruct users of my library to use StrongNameSigner

[brutaldev]

@jakubmisek That really depends. Any project that is strong-name signed is required to only reference other strongly-named assembles. If you provide a NuGet package that is signed you wouldn't be able to reference a non-signed package like ImageSharp anyway. What the tool provides is the ability for people that have strong-named projects to use non-signed libraries but signing those incompatible assemblies for you pre-build so you don't get unsigned assembly error messages.

[majdisorder]

Couldn't get it to work at first glance using @brutaldev's solution. I'll revisit this when I have a bit more time. Pointers are welcome.

I can't seem to find a ballpark date for the RC. I found this: https://myget.org/gallery/imagesharp-latency but it seems unofficial and it's over two years old.

Can we expect an RC soon, or should I forge ahead trying to self sign? I'm in the middle of a POC and don't want to waste time unnecessarily (don't we all :) ).

[jakubmisek]

@dimi3tron we'll probably fork, sign the build and upload signed nugets by ourselves ... this is ridiculous :)

[majdisorder]

@jakubmisek sounds like a safe bet.

I see you're peachpie contributor, so I hope you're planning to include the fork in the next release because that is exactly what I need them for.

[JimBobSquarePants]

There’s a dated RC1 milestone in the repo. Please read before calling things ridiculous.

[antonfirsov]

@jakubmisek @dimi3tron there is an ongoing repository+package structure consolidation (#1002), which will be finished soon. After that, strong naming gets high priority.

[jakubmisek]

@JimBobSquarePants @antonfirsov thank you! looking forward to it :)
"Ridiculous" is the library cannot be used on .NET Framework for 3 years already while the fix is a single line of XML .. I won't be crying over it anymore :)

[PureKrome]

Ridiculous is the fact that MS are still fricking thrashing this legacy "strong-naming" crap around in 2020. This 💩 should have long been turfed when .NET core was born.

"Line in the sand" and all...

Sorry @JimBobSquarePants and krew for having to put up with this crap, still 😢

[JimBobSquarePants]

If we implement the shared-infrastructure props as defined here, I see no reason why we cannot start signing our nightlies before the RC1 release.

#867 (comment)

[antonfirsov]

@JimBobSquarePants I don't think #867 is a blocker, since everything is in the ImageSharp repo now. We can add the necessary changes at ImageSharp's props/targets/csproj level, and consolidate later, probably when adapting stuff to Drawing. (We have a bunch of stuff to move to the shared infra anyways.)

I would prioritize this, and stress to do it in the next few weeks, but not sure if I personally have the time because of the memory refactor.

[bfistein]

May I ask how this will work for OSS projects in relation to your upcoming license change? NuGet only supports one license AFAIK, so I assume your package will be licensed under GPL. Is the intention for projects with a dependency on ImageSharp to use a previous version under Apache 2.0 and sign it themselves? Or do you have another solution in mind?

[SimonCropp]

@bfistein

NuGet only supports one license AFAIK,

NuGet supports SPDX, which allows for compound expression https://docs.microsoft.com/en-us/dotnet/core/tools/csproj#packagelicenseexpression

[antonfirsov]

The strong naming fix is on the way!

Re licensing:
@SimonCropp the how does SPDX work with the licensing model we plan to introduce?

#1024 TLDR:

license := 
    if "Has subscription" => Commercial
    else if "OSS project with ImageSharp dependency taken before RC1" => Apache 2.0
    otherwise => AGPLv3**

** probably with an additional exception clause.