Handle TAR uid/gid values larger than int.MaxValue

[am11]

Unix uid_t/gid_t are unsigned. Reading a GNU base-256 or PAX uid/gid
above Int32.MaxValue threw OverflowException. Reinterpret such values
as int without an overflow check, matching what TarWriter already does
for file system ids, and write negative ids back as unsigned in the GNU
header field and PAX extended attributes so they roundtrip.

Fixes #127006

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-formats-tar
See info in area-owners.md if you want to be subscribed.

[rzikm]

What happens if id is bigger than uint? is it still okay to truncate it? I am wondering if it would not be better to introduce long variants for the properties

[am11]

@rzikm, good point. uid_t/gid_t are 32-bit unsigned on our Unix targets, so anything that doesn't fit in 32 bits can't be a real id. It now throws InvalidDataException instead of truncating.

I'd rather not add long properties here: the real range is uint, so they wouldn't carry more information, and they'd need API review. Happy to open a separate proposal if you think it's worth it.

[rzikm]

I'd rather not add long properties here: the real range is uint, so they wouldn't carry more information, and they'd need API review. Happy to open a separate proposal if you think it's worth it.

no, if the valid range is 32 bits only, then allowing negative numbers seems like a good compromise.

[am11]

SslStream failure is unrelated.

[rzikm]

LGTM, thanks

[rzikm]

/ba-g SslStream failure is #134925

[tskala-gordic]

Would you consider backporting this fix to .NET 10?

[rzikm]

Would you consider backporting this fix to .NET 10?

Sure, can you briefly explain your scenario and what impact the issue has for you? Are there some workarounds that you can use?

Having some justification will make it easier to get the backport approved.

[tskala-gordic]

Our CI/CD tooling explores component packages from nuget/npm/github for metainfo/licenses updates. And it fails on one of them

https://registry.npmjs.org/d3-timelines/-/d3-timelines-1.3.1.tgz

It's entry PaxHeader/package/README.md, has a GNU base-256 UID field containing 80 00 00 00 A8 19 40 05 (2,820,227,077). TarReader.GetNextEntry() throws OverflowException while parsing that field into Int32 on .NET 10.0.12. Windows tar (libarchive) successfully reads the archive.

As hotfix we processed it manually and filled it as static information (it's old so it won't change anyway). Hoping future packages won't fail the same way. Using new/alternative tar (NET) unzippers is problematic. We would use external unzipper if necessary. It's not critical but this fix seems to solve it within native NET libraries.