Skip to content

Added strong naming #116

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Dec 11, 2017
Merged

Added strong naming #116

merged 2 commits into from
Dec 11, 2017

Conversation

darrelmiller
Copy link
Member

@darrelmiller darrelmiller commented Dec 11, 2017

Added file Microsoft.OpenApi.snk with public/private key pair. Microsoft.OpenAPI and Microsoft.OpenApi.Readers are now identified using this public key. Addresses #110

Microsoft OSS guidelines do not require authenticode code signing of libraries for the purpose of releasing them. Teams using this library for Microsoft products will be required to sign the library at the point of building the product.

@PerthCharern
Copy link
Contributor

Sorry I’m new when it comes to managing assemblies, so this might be a bad question.

If we include the privake key with the snk, does this mean someone else can package this assembly and pretend to be us? Wouldn’t that defeat the purpose of strong naming?

@darrelmiller
Copy link
Member Author

darrelmiller commented Dec 11, 2017

Yes, someone else can take this source code and build it with the same identity. No that doesn't defeat the purpose of strong naming. The purpose of strong name is to provide a globally unique identity. It was demonstrated in recent years that strong naming does not provide a security guarantee and shouldn't be trusted to do so. The Microsoft docs now explicitly warn against relying on Strong Naming for security https://docs.microsoft.com/en-us/dotnet/framework/app-domains/strong-named-assemblies

You can see from the msbuild project that the .snk file is included https://github.com/Microsoft/msbuild/tree/master/src in the source repo.

Security is provided by using Authenticode signing as part of a build process. This can guarantee that the binaries have not been touched since the build. Even 3rd party binaries that have already been signed have to be signed again during the build process.

@PerthCharern
Copy link
Contributor

Thanks for the detailed response Darrel. That makes sense now. I’ll sign off.

@darrelmiller darrelmiller merged commit 395bb87 into master Dec 11, 2017
@darrelmiller darrelmiller deleted the dm/strong-name branch December 11, 2017 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants