[release/5.0] Handle inconsistent \0 in Pkcs9Document{Name|Description} #45153
Conversation
|
Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @jeffhandley |
|
@joperezr Hm, this is in an OOB... I probably need to do things like manually bump the package version and add it to packages to rebuild, instead of just letting the port bot port the change, right? |
|
Yes that is correct you will want to manually add those two changes as extra commits to this PR as the bot won’t know it needs to do that. If you want an example, just check how it was done on this already merged servicing PR https://github.com/dotnet/runtime/pull/43903/files Basically you want to pay attention to the change made on the library’s directory.build.props that bumps the package and assembly versions, and also the change into libraries-packages.proj where the build of this package is manually added to the build. Finally, if you manually build this locally you can use the UpdatePackageIndex target to maje the required uodates on the package index by building: dotnet msbuild yourlibrary.pkgproj /t:UpdatePackageIndex |
|
It found that we hadn't indexed version 4.7.0, but it didn't also add an entry in the assembly-version-to-package-version part. I'm not sure if that's sensible or not. (it had 4.7.0 as the last item in that list, I moved it to be sorted) |
|
@bartonjs there is a relevant failure on the net48 leg. |
|
OOB packaging changes looks good to me.
Mmm that is weird, it would be interested to check what other changes were made by our task.
It is not really an issue. The tool can't find that information very trivial (it would need to download all packages that we have ever shipped for that library) since that table tells you the first package version where a new assembly version was included. We use that table in case some other library references Pkcs and specifically reference an older assemblyVersion like 4..0.4.0 for example, and so our packaging infrastructure would emit a package reference to version 4.6.0 of the Pkcs package, which is the lowest one where that assembly version appeared. All that said, this condition breaks whenever the baseline version is higher, and today we have it set to 5.0.0 so it doesn't really matter to get any new assembly version that showed up in 4.7.0 package. I hope at least some part of the above explanation made sense, but the TLDR version is: The changes on the packageIndex you made look correct. |
This looks like it's a machine issue, I have a ticket with engineering to get it worked out. It passed in master, and then a later run hit the same machine it failed on here. #45168 is our side of tracking the failure, though it'll hopefully just stop happening once any machines with problems are cleared up. |
|
Oops, I didn't see your last comment @bartonjs - I just merged based on signoff, the machine issue and Jose's signoff |
Backport of #45040 to release/5.0
/cc @bartonjs
Customer Impact
Customers migrating from .NET Framework get different answers for Pkcs9DocumentName.Name and Pkcs9DocumentDescription.Description when the contents contain embedded NUL characters or lack the canonical trailing NUL character.
Testing
New tests added for both embedded NUL and missing NUL
Risk
Low