Repository navigation
Strong name the releases please #738
Description
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.
Activity
antonfirsov commentedon Oct 17, 2018
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 commentedon Oct 18, 2018
Yeah, the tide has definitely turned. RC1 shall be strong named.
etomm commentedon Nov 14, 2018
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 commentedon Nov 14, 2018
That’s utter bollocks. Strong naming should never be used for security. MS literally warn you not to in their documentation.
astrowalker commentedon Nov 14, 2018
@JimBobSquarePants , could you please pass a link and a quote. Thank you in advance.
JimBobSquarePants commentedon Nov 14, 2018
https://docs.microsoft.com/en-us/dotnet/framework/app-domains/strong-named-assemblies
etomm commentedon Nov 14, 2018
@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 commentedon Nov 14, 2018
brutaldev commentedon Dec 6, 2019
In the meantime you can use my Strong-Name Signer tool to do it for you: https://github.com/brutaldev/StrongNameSigner/
jakubmisek commentedon Dec 6, 2019
it works for executable projects right? not the libraries
brutaldev commentedon Dec 7, 2019
@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 commentedon Dec 9, 2019
@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 commentedon Dec 9, 2019
@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 commentedon Jan 17, 2020
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 commentedon Jan 17, 2020
@dimi3tron we'll probably fork, sign the build and upload signed nugets by ourselves ... this is ridiculous :)
majdisorder commentedon Jan 17, 2020
@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 commentedon Jan 17, 2020
There’s a dated RC1 milestone in the repo. Please read before calling things ridiculous.
antonfirsov commentedon Jan 17, 2020
@jakubmisek @dimi3tron there is an ongoing repository+package structure consolidation (#1002), which will be finished soon. After that, strong naming gets high priority.
jakubmisek commentedon Jan 21, 2020
@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 commentedon Jan 21, 2020
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 commentedon Jan 26, 2020
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 commentedon Feb 9, 2020
@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 commentedon Feb 16, 2020
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 commentedon Feb 17, 2020
@bfistein
NuGet supports SPDX, which allows for compound expression https://docs.microsoft.com/en-us/dotnet/core/tools/csproj#packagelicenseexpression
antonfirsov commentedon Feb 27, 2020
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:
** probably with an additional exception clause.