Stripe.net missing strong name

[kartikbb]

I added Stripe.net from NuGet. I found that the dlls arent strong named. Since we have a mandate to use strong names ones, could you release one on nuget?

[jaymedavis]

Sure - I'll look into this asap. Thanks.

On Wed, Sep 19, 2012 at 1:14 PM, kartikbb notifications@github.com wrote:

I added Stripe.net from NuGet. I found that the dlls arent strong named.
Since we have a mandate to use strong names ones, could you release one on
nuget?

—
Reply to this email directly or view it on GitHubhttps://github.com/jaymedavis/stripe.net/issues/40.

[CerebralMischief]

Easy enough, just generate a key and attached it in the project properties. Store that key with your code and use the same key in any projects in the .SLN. Strong Signing an assembly allows it to be placed in the GAC.

[jaymedavis]

Did you not need this anymore? I tried a couple of times to get it working, but it was being a real PITA. :(

[kartikbb]

I followed what Eric suggested and got this resolved

[jaymedavis]

Cool - thanks for the update and for closing.

On Wed, Jan 23, 2013 at 10:45 PM, kartikbb notifications@github.com wrote:

I followed what Eric suggested and got this resolved

—
Reply to this email directly or view it on GitHubhttps://github.com/jaymedavis/stripe.net/issues/40#issuecomment-12635859.

[xecrets]

I know this is closed, but should really not be a problem to add a strong name - because that's all it is. It's not a security feature, it's about a stronger assembly naming mechanism. You can check in the private key in the repository and have it password-less so it doesn't really impact the build at all. (If you'd like you can make the strong naming conditional but that requires indeed some tricks and configuration of the release build environment. I guess that's where the PITA might be felt.)

I'd be happy to fix it, if you'd accept a pull request. I was forced to turn off strong naming my assemblies because of this, since it's not allowed to reference a non-strong named assembly from a strong-named one.

[CerebralMischief]

Actually strong signing an assembly is technically a security feature because that assembly cannot be changed without breaking the sign. It's useful for ensuring that malware does not alter it and leaving the user with no idea. Of course signing it with no password does away with all of that because anyone can fork the code and malicious code and resign it thus making it appear to come from the original author. I would recommend leaving it up to the end user to strong sign it if it's really required or make it a part of the build process.

Just my two cents, the choice is obviously up to you Jayme. :)

-Eric

[jaymedavis]

So, I guess ideally it's better to sign the assemnly ONLY if I password protect the signing, for the reasons @ericsb mentioned.

I'm not against signing it with a password if its a security feature for the users to confirm it came from the right place. This is just something I'm not that familiar with - but it sounds like it is worth some time to revisit and research.

Was your plan to submit the PR with instructions on signing it with a secret token? With that said, I'm not sure of the impact to existing users.

I can swallow my pride on this one and just admit I don't know what's best to do in this circumstance - I'm going to reopen and investigate again. Any additional info is welcome on pros/cons and links!

[CerebralMischief]

Here is a link with more information if you're interested. https://visualstudiomagazine.com/articles/2013/05/01/creating-secure-applications.aspx?m=1

Hope that helps and feel free to reach out to me if you'd like any assistance.

Eric

Get Outlook for Android

On Mon, Oct 10, 2016 at 10:57 PM -0400, "Jayme Davis" notifications@github.com wrote:

Reopened #40.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/jaymedavis/stripe.net/issues/40#event-818871725

[xt0rted]

Microsoft says in their docs that strong-naming isn't a security feature. https://msdn.microsoft.com/en-us/library/wd40t7ad.aspx

This is also reiterated in the corefx docs strong-name-signing.md#2-i-really-really-need-to-strong-name-what-kinds-of-issues-will-i-run-into where they say open source projects should include the key in the repo to make it easier for development & custom builds.

Adding this won't affect me aside from binding redirects, but the illusion of security is why I and everyone else who tried to get this removed from .net core give it a 👎

[xecrets]

Hello,

With all due respect @ericsb, as @xt0rted notes Microsoft officially clearly states that Strong Naming is not a security feature. In fact, it's the first thing that shows up in a quote-box if you google "microsoft strong name".

That it's technically based on a digital signature is what's led to this long-time misconception. It's even displayed as a warning note in the documented linked to above:

.

That an independent contractor promotes this old misunderstanding in an article under the Visual Studio Magazine heading doesn't change the fact and really just goes to show how hard it is to change perceptions once they've been set.

If it was as easy as leaving it up to the end user to sign it @ericsb, it would never have been an issue. The problem is that it can only be done by recompiling the source code (except for some really ugly hacks) rules out nuget distribution of a ready built binary without the strong name should the user (like me) actually need one.

For security in the sense that you want to ensure the authenticity and integrity of a distributed binary, an Authenticode signature should be used. https://msdn.microsoft.com/en-us/library/ms537359(v=vs.85).aspx .

Strong naming an assembly does not affect existing users when you make the switch - as long as you do not have a dependency in your turn which is currently not strong named and thus require upgrading as well. A non-strong named assembly can reference a strong named or non-strong named assembly, but a a strong named asssembly can only reference other strong named assemblies. So, no, there's no impact for existing users to go from not strong naming to strong naming. Going forward, consumers of the strong named assembly may need to add binding redirects if they wish to reference an updated version of your strong named assembly without recompiling their own, or if they use other assemblies which in turn reference different versions of your strong named assembly. But, that's the exactly the point of strong naming! To ensure that that the consumer get's exactly the version that it was built for (assuming non-malign developers, it's not meant to protect against deliberate attempts to fool the consuming assembly).

Strong naming an assembly does not cause a ripple effect upwards in the chain of references. Not strong naming forces all consumers 'above' in the chain of reference to not being strong named, leaving them without a choice and causing situations where your assembly simply cannot be consumed.

Finally, I do agree with @xt0rted that because of the wide misunderstanding of the technology it might be time to retire strong naming. But it can't be done unilaterally by developers - it would have to be done by the authors of the .NET framework, so we'll just have to live with it. Including the strong name private key without a password on the open source repository is currently the simplest way to handle the situation with least impact.

[xt0rted]

This topic has been beat to death many times before, probably the biggest thread on it is octokit/octokit.net#405 if you have time to kill 😄

Something mentioned either in that issue or one of the linked issues is using https://github.com/dsplaisted/strongnamer so the onus is on the consumer, not the publisher.

[xecrets]

Haha - beaten to death with a vengeance in that thread! Thanks for linking @xt0rted . Anyway, although I do not have time enough to kill to really read every entry, I found no strong (pun intended) arguments against strong naming there. In fact, a ton of very popular open source libraries do, and they include the key in the repo. Anyone had any critical problems with Json.NET being strong named lately?

So, the executive summary as I see it is:

• Strong name w/key in repo: No problems, except potential for binding redirects. Proven over time.
• No strong name: Insurmountable (almost...) problems for strong named consumers.

The https://github.com/dsplaisted/strongnamer is exactly the type of hack I think should be avoided. It also increases the build time, and importantly - it completely removes the possibility to actually really sign the assembly with Authenticode, since the hack will modify the assembly and thus invalidate the real signature.

[xt0rted]

Json.NET is strong named, but the assembly version is locked with each major release. Right now it's 9.0.0.0 despite the latest version on NuGet being 9.0.1 and the assembly file version being 9.0.1.19813. That helps elevate some of the issues people have with strong naming and is probably the best compromise.

[xecrets]

+1 for @xt0rted . That's indeed a common solution to reduce the binding redirect potential problem, and was proposed on the octokit thread as well. It's then up to the publisher to keep the promise being made by the assembly version. While there are theoretical issues with this model, in actual practise it's a good compromise. (A bug fix for example by definition changes the behavior, and you then have the potential risk of a consumer compensating for the bug in the previous version, and being silently broken by the fixed assembly with the same version number....).

[ybhatti]

Hi, any news on when the dll will be made strongly typed?
I want to start using stripe but not if it means not having a strongly typed dll.
I can do work arounds but prefer the nuget source to be updated for future safety.

[brandur-stripe]

I'm not sure I'm going to get to this right away, but it does seem like something we should do. This AppVeyor questions lays out a rough set of steps for how this might be accomplished.

[ybhatti]

I've actually removed the strongly typed dlls from my project now so that i can use the stripe dll as it is.
I read an article about the worth of having signed assemblies....didn't seem worth it.
https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/
Maybe the way you've got it is good enough?

[ob-stripe]

Hi @ybhatti, thanks for sharing this! Very interesting. We will definitely take this into account before making a decision on strong-naming.

[ob-stripe]

I've just spent some time researching this issue. The situation may have changed since this issue was opened (5+ years ago), and the consensus nowadays seems to be that open-source libraries should not use strong-naming. Users who really need strong-naming can always use tools such as this one to do it themselves.

I'm going to remove the future tag and close this issue.

References:

• Signed Octokit Releases - Yea or Nay? octokit/octokit.net#405
• Strong Name reactiveui/ReactiveUI#43
• https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md