Skip to content

Add the ability to use the .NET certificate with a switch#7347

Merged
mmitche merged 3 commits into
dotnet:mainfrom
mmitche:add-ability-to-use-dotnet-cert
May 6, 2021
Merged

Add the ability to use the .NET certificate with a switch#7347
mmitche merged 3 commits into
dotnet:mainfrom
mmitche:add-ability-to-use-dotnet-cert

Conversation

@mmitche

@mmitche mmitche commented May 5, 2021

Copy link
Copy Markdown
Member

A subset of arcade repositories will ship .NET 6 using a different certificate for most executable files. This leads to a question: How to specify that this cert should be used rather than Microsoft400? There are a number of options:

  1. Use certificate replacement in post-build signing to switch all uses of Microsoft400 to MicrosoftDotNet500 - This has the disadvantage that if there are any binaries that still need to ship to end-customers with Microsoft400, they would get the new cert. It's also a little hacky, and certificate replacement was only intended for limited use by internal customers in specific scenarios.
  2. Update default metadata in each repo that needs to switch to specify MicrosoftDotNet500 instead of Microsoft400 - This is easy to do for explicit specifications in a repo's eng/Signing.props file, but the arcade defaults are still present. They can be replaced with something like:
    <!-- Update existing defaults from arcade that were using Microsoft400 to use the .NET-specific cert -->
    <ItemGroup>
      <FileExtensionSignInfo Update="@(FileExtensionSignInfo->WithMetadataValue('CertificateName','Microsoft400'))" CertificateName="MicrosoftDotNet500" />
      <StrongNameSignInfo Update="@(StrongNameSignInfo->WithMetadataValue('CertificateName','Microsoft400'))" CertificateName="MicrosoftDotNet500" />
    </ItemGroup>
    
    However, this bit of code isn't entirely easy to understand, would have to be inserted into every repo.
  3. Change the arcade default to MicrosoftDotNet500 - This has wide-ranging implications for repos that we don't want to change, at least not now. I think this will eventually be an option, but is too risky with too many unknowns right now.
  4. Introduce a new property UseDotNetCertificate which can be set in eng/Signing.props. This causes all existing use of Microsoft400 in the repo to switch to MicrosoftDotNet500. This is the preferable for repos repos that use arcade defaults for most things (use Sign.proj and Publish.proj). The certificate metadata update happens prior to signing or encoding of the signing metadata in the manifests.

Repos should use a combination of 4 and 2 for now to update to the .NET cert.

Tests will be added in arcade-validation.

To double check:

A subset of arcade repositories will ship .NET 6 using a different certificate for most executable files. This leads to a question: How to specify that this cert should be used rather than Microsoft400? There are a number of options:
1. Use certificate replacement in post-build signing to switch all uses of Microsoft400 to MicrosoftDotNet500 - This has the disadvantage that if there are any binaries that still need to ship to end-customers with Microsoft400, they would get the new cert. It's also a little hacky, and certificate replacement was only intended for limited use by internal customers in specific scenarios.
2. Update default metadata in each repo that needs to switch to specify MicrosoftDotNet500 instead of Microsoft400 - This is easy to do for explicit specifications in a repo's eng/Signing.props file, but the arcade defaults are still present. They can be replaced with something like:
   ```
   <!-- Update existing defaults from arcade that were using Microsoft400 to use the .NET-specific cert -->
   <ItemGroup>
     <FileExtensionSignInfo Update="@(FileExtensionSignInfo->WithMetadataValue('CertificateName','Microsoft400'))" CertificateName="MicrosoftDotNet500" />
     <StrongNameSignInfo Update="@(StrongNameSignInfo->WithMetadataValue('CertificateName','Microsoft400'))" CertificateName="MicrosoftDotNet500" />
   </ItemGroup>
   ```
   However, this bit of code isn't entirely easy to understand, would have to be inserted into every repo.
3. Change the arcade default to MicrosoftDotNet500 - This has wide-ranging implications for repos that we don't want to change, at least not now. I think this will eventually be an option, but is too risky with too many unknowns right now.
4. Introduce a new property `UseDotNetCertificate` which can be set in eng/Signing.props. This causes all existing use of Microsoft400 in the repo to switch to MicrosoftDotNet500. This is the preferable for repos repos that use arcade defaults for most things (use Sign.proj and Publish.proj). The certificate metadata update happens prior to signing or encoding of the signing metadata in the manifests.

Repos should use a combination of 4 and 2 for now to update to the .NET cert
@mmitche
mmitche requested a review from chcosta May 5, 2021 21:15

@chcosta chcosta left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for updating the documentation as well!

@mmitche
mmitche merged commit f9ce605 into dotnet:main May 6, 2021
@mmitche
mmitche deleted the add-ability-to-use-dotnet-cert branch February 9, 2022 18:53

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

charts/kube-prometheus-stack/templates/prometheus/rules-1.14/kubernetes-apps.yaml

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.

4 participants