Skip to content
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

Localized artifacts now contain Authenticode signed assemblies #6172

Open
wants to merge 2 commits into
base: dev
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions docs/localizability.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,9 +24,11 @@ Unfortunately, NuGet.Client does not use OneLocBuild, and any resource comments
Although the steps below are for the dev branch, the process is similar for release branches.

1. A PR merges into the dev branch.
1. A NuGet.Client build generates a `localizationArtifacts` artifact. This artifact contains newly built (but unsigned) assemblies and .lcg files. The .lcg files contain information extracted from .resx files and are the primary input for later localization.
1. A NuGet.Client build generates a `localizationArtifacts` artifact. This artifact contains newly built Authenticode-signed assemblies [(see PR#6170)][12]) containing English resources and .lcg files.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
1. A NuGet.Client build generates a `localizationArtifacts` artifact. This artifact contains newly built Authenticode-signed assemblies [(see PR#6170)][12]) containing English resources and .lcg files.
1. A NuGet.Client build generates a `localizationArtifacts` artifact. This artifact contains newly built assemblies containing English resources and .lcg files.

If someone needs to investigate the loc process in a year or more from now, I'm not sure why the PR would be interesting to call out specifically. In fact, the fact that it's signed or not also doesn't seem important to me.

The loc team's tools don't have a requirement about signed or unsigned assemblies.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The loc team's tools don't have a requirement about signed or unsigned assemblies.

This documentation is for the NuGet Client team, not the loc team.

In fact, the fact that it's signed or not also doesn't seem important to me.

The original document indicated that these were unsigned assemblies. This is an update reflecting the new state of these assemblies.
This change is part of the SFI work to ensure we sign assemblies. If localized assemblies are not signed, we are no longer meeting SFI requirements.

The .lcg files contain information extracted from .resx files and are the primary input for later localization.
1. The localization team grabs the `localizationArtifacts` artifact from a NuGet.Client build.
1. The localization team localizes strings and merges a ["LEGO" PR][5] with localized strings (in .lcl files).
1. The localization team localizes strings.
The signed assemblies are used to validate the exported .lcl won't break the build before the team merges a ["LEGO" PR][5] with localized strings (in .lcl files).
donnie-msft marked this conversation as resolved.
Show resolved Hide resolved
1. During the next NuGet.Client build, the build adds the [NuGet.Build.Localization][6] repository as a submodule of the NuGet.Client repository and checks out a branch of the same name as the NuGet.Client repository (e.g.: dev, release-6.7.x, etc.). Localized resources are [made available][7] to localized builds through the `NuGetBuildLocalizationRepository` property.
1. When the build completes, the product is localized using localizations based on an earlier commit. (This means strings added since then won't be localized.)

Expand Down Expand Up @@ -149,4 +151,5 @@ private void DoSomething(ILogger logger)
[8]: https://github.com/NuGet/NuGet.Build.Localization/blob/931c5f21742fff61c7f53a19039b89dddc7a01cd/localize/comments/15/NuGet.Packaging.dll.lci#L58-L66
[9]: https://github.com/dotnet/sign/blob/ef0e6b3ef8281dff1d62cea34445bd88fc3e6714/src/Sign.Core/Resources.resx#L131-L134
[10]: https://aka.ms/allaboutloc
[11]: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/20709/MicroBuild-Localization
[11]: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/20709/MicroBuild-Localization
Copy link
Member

Choose a reason for hiding this comment

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

Similar to another comment, it's not clear to me why someone reading these docs would be more interested in this pull request than any other pull request that modified build/loc.proj or the build yaml.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This pull request contains an explanation of why it's important to sign the localized assemblies, as well as how it's being done. It's not accidental that they're signed, it is intentional, so the documentation is referencing that PR to point to the purpose of that behavior.

[12]: https://github.com/NuGet/NuGet.Client/pull/6170
Loading