[release/7.0] Fix PAX extended attribute reading logic to treat '=' character as valid in the value strings.

[github-actions]

Backport of #82810 to release/7.0

/cc @carlossanlop

Customer Impact

The dotnet/sdk-container-builds team reported that they were unable to read TAR entries in the PAX format that contained the = character in their extended attribute metadata.

In the PAX TAR format, each entry representing a filesystem object is always preceded by an entry containing only metadata information in its data section. This metatada is known as extended attributes, and they are stored in the form of key-value-pairs, where the separator character between keys and values is the = character, and the separator of one key-value with another is the \n character.

The sdk-container-builds team is using those extended attributes to store Windows Security Descriptor data. An example of a value that they were unable to read is:

• Key: [MSWINDOWS.rawsd](https://github.com/buildpacks/rfcs/blob/main/text/0076-windows-security-identifiers.md)
• Value: AQAAgBQAAAAkAAAAAAAAAAAAAAABAgAAAAAABSAAAAAhAgAAAQIAAAAAAAUgAAAAIQIAAA==

The root cause of this bug is that we were explicitly disallowing any = characters in the value part of the key-value-pair, after detecting the very first one and considering it the separator. In reality, the TAR spec does not specify that this restriction should be in place, and we should allow any number of = characters in the value section, since we only care about the first one.

So the fix was to remove the code block that was preventing the use of more than one =.

Testing

• Manually compared the behavior of our APIs to that from the Ubuntu gnu tar tool to ensure the behavior was not unexpectedly different.
• Manually tested the APIs with the code fix to ensure we could write and read entries with such metadata.
• Added unit tests to verify that we are able to accept key-value-pairs that contain various combinations of = characters in the value string, both in our sync and async APIs.
• Added round-trip tests to ensure we can write and read entries with this kind of metadata.

Risk

Low.

The fix just removes an if block that prevented a desired behavior.

Even though the PAX format is the default one in our TarFile APIs, users can only specify custom extended attributes when manually constructing a TAR archive using the advanced APIs: a TarWriter instance, and the PaxTarEntry constructor that takes a dictionary.

No OOB changes needed for this assembly.

Notes

Fixing this issue made us discover that we could add more robust validation in the PaxTarEntry constructor that takes a dictionary of key-value-pairs to use as extended attributes, to safe-guard users from creating TAR archives that contain forbidden characters in these values. We will merge that fix in .NET 8. It may not meet the bar for a backport by itself.

[carlossanlop]

Approved by Tactics via email.
Signed-off.
No OOB changes needed.
CI failure is unrelated.
Ready to merge.