Avoid rooting cryptography through ZipArchive on browser

[Copilot]

Fixes#130650
which is regression from #122093

Using ZipArchive on browser-wasm unnecessarily retained System.Security.Cryptography, increasing trimmed application size even though WinZip AES is unsupported there.

Changes

• Exclude WinZip AES implementation files and the cryptography project reference from browser builds.
• Provide browser-specific WinZip AES stubs that continue throwing PlatformNotSupportedException.
• Keep ZipCrypto supported by removing its cryptography dependency:
  • Generate header randomness with Guid.NewGuid().
  • Clear pooled password buffers with Array.Clear.
• Add coverage ensuring browser ZipCrypto remains functional and the wasm dependency closure excludes System.Security.Cryptography.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
12 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 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot was unable to review this pull request because there is no eligible user to bill. To allow Copilot reviews on bot-authored pull requests, enable direct organization billing in your organization's Copilot settings.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1072

• This browser-only test validates ZipCrypto decryption, but this PR also changes browser behavior by swapping in WinZip AES stubs. Consider also asserting that opening the AES-encrypted entry in the same archive throws PlatformNotSupportedException, so the new stub path is exercised on Browser and regressions are caught.

 ZipArchiveEntry entry = archive.GetEntry("hello.txt");
Assert.NotNull(entry);
Assert.Equal(ZipEncryptionMethod.ZipCrypto, entry.EncryptionMethod);
using Stream entryStream = await OpenEntryStream(async, entry, Password);
using StreamReader reader = new(entryStream);

src/libraries/Common/src/Interop/Windows/BCrypt/Interop.BCryptGenRandom.GetRandomBytes.cs:30

• GetCryptographicallySecureRandomBytes currently forwards to GetRandomBytes, which throws InvalidOperationException on most failures. Since the method name (and the Unix implementation) implies cryptographic RNG semantics, it should throw CryptographicException for non-OOM failures to better match RandomNumberGenerator behavior.

 // BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG is always cryptographically secure.
internal static unsafe void GetCryptographicallySecureRandomBytes(byte* buffer, int length) =>
GetRandomBytes(buffer, length);

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:785

• keySizeBits is computed but never used in this AES update-mode path. This is dead code and can produce warnings / confusion; it should be removed (the key size was already baked into _derivedAesKeyMaterial).

 // Determine the actual compression method to use
// The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:9

• The WinZipAesKeyMaterial stub is declared as internal readonly struct WinZipAesKeyMaterial; which is not valid C# syntax (types can’t be forward-declared with a trailing semicolon). This will fail to compile on browser builds.

 internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System.IO.Compression.csproj:128

• System.Security.Cryptography doesn’t target $(NetCoreAppCurrent)-wasi (its csproj only includes windows/unix/android/apple/browser/$(NetCoreAppCurrent)), so keeping this ProjectReference for wasi will break the wasi build. The condition should exclude wasi as well as browser.

 <ProjectReference Include="$(LibrariesProjectRoot)System.Security.Cryptography\src\System.Security.Cryptography.csproj" Condition="'$(TargetPlatformIdentifier)' != 'browser'" />

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:10

• WinZipAesKeyMaterial is declared with a trailing semicolon, which isn’t valid C# (C# doesn’t support forward-declaring structs). Browser builds will fail to compile this file.

{
internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:786

• In this AES update-mode branch, int keySizeBits = GetAesKeySizeBits(Encryption); (a few lines above) is assigned but never used. If warnings are treated as errors, this will break the build; if the call is only for validation, discard the value explicitly.

 // The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(
baseStream: _archive.ArchiveStream,

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1078

• This browser-only test validates ZipCrypto decryption, but it doesn’t cover creating a ZipCrypto entry on browser. Since this PR changes the ZipCrypto encryption path (header salt generation + password buffer clearing), adding a round-trip create/read assertion here would help prevent regressions.

 using MemoryStream createStream = new();
ZipArchive createArchive = await CreateZipArchive(async, createStream, ZipArchiveMode.Create, leaveOpen: true);
Assert.Throws<PlatformNotSupportedException>(() => createArchive.CreateEntry("aes.txt", Password, ZipEncryptionMethod.Aes256));
await DisposeZipArchive(async, createArchive);
}

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs:626

• ReadEncryptionSaltIfNeeded now returns early on browser/wasi without populating _aesSalt. In the sync open path (WrapWithDecryptionIfNeeded), AES entries first check _aesSalt is null and throw InvalidDataException(SR.LocalFileHeaderCorrupt), so on browser/wasi this can surface as “corrupt header” instead of the intended PlatformNotSupportedException for WinZip AES. Consider setting a non-null sentinel salt on browser/wasi so the open path reaches the WinZipAesStream stubs and throws PNSE consistently.

 if (!IsAesEncrypted || !_originallyInArchive || OperatingSystem.IsBrowser() || OperatingSystem.IsWasi())
{
return;
}

[alinpahontu2912]

/ba-g failure unrelated to my change

[Copilot]

Fixes#130650
which is regression from #122093

Using ZipArchive on browser-wasm unnecessarily retained System.Security.Cryptography, increasing trimmed application size even though WinZip AES is unsupported there.

Changes

• Exclude WinZip AES implementation files and the cryptography project reference from browser builds.
• Provide browser-specific WinZip AES stubs that continue throwing PlatformNotSupportedException.
• Keep ZipCrypto supported by removing its cryptography dependency:
  • Generate header randomness with Guid.NewGuid().
  • Clear pooled password buffers with Array.Clear.
• Add coverage ensuring browser ZipCrypto remains functional and the wasm dependency closure excludes System.Security.Cryptography.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
12 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 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot was unable to review this pull request because there is no eligible user to bill. To allow Copilot reviews on bot-authored pull requests, enable direct organization billing in your organization's Copilot settings.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1072

• This browser-only test validates ZipCrypto decryption, but this PR also changes browser behavior by swapping in WinZip AES stubs. Consider also asserting that opening the AES-encrypted entry in the same archive throws PlatformNotSupportedException, so the new stub path is exercised on Browser and regressions are caught.

 ZipArchiveEntry entry = archive.GetEntry("hello.txt");
Assert.NotNull(entry);
Assert.Equal(ZipEncryptionMethod.ZipCrypto, entry.EncryptionMethod);
using Stream entryStream = await OpenEntryStream(async, entry, Password);
using StreamReader reader = new(entryStream);

src/libraries/Common/src/Interop/Windows/BCrypt/Interop.BCryptGenRandom.GetRandomBytes.cs:30

• GetCryptographicallySecureRandomBytes currently forwards to GetRandomBytes, which throws InvalidOperationException on most failures. Since the method name (and the Unix implementation) implies cryptographic RNG semantics, it should throw CryptographicException for non-OOM failures to better match RandomNumberGenerator behavior.

 // BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG is always cryptographically secure.
internal static unsafe void GetCryptographicallySecureRandomBytes(byte* buffer, int length) =>
GetRandomBytes(buffer, length);

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:785

• keySizeBits is computed but never used in this AES update-mode path. This is dead code and can produce warnings / confusion; it should be removed (the key size was already baked into _derivedAesKeyMaterial).

 // Determine the actual compression method to use
// The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:9

• The WinZipAesKeyMaterial stub is declared as internal readonly struct WinZipAesKeyMaterial; which is not valid C# syntax (types can’t be forward-declared with a trailing semicolon). This will fail to compile on browser builds.

 internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System.IO.Compression.csproj:128

• System.Security.Cryptography doesn’t target $(NetCoreAppCurrent)-wasi (its csproj only includes windows/unix/android/apple/browser/$(NetCoreAppCurrent)), so keeping this ProjectReference for wasi will break the wasi build. The condition should exclude wasi as well as browser.

 <ProjectReference Include="$(LibrariesProjectRoot)System.Security.Cryptography\src\System.Security.Cryptography.csproj" Condition="'$(TargetPlatformIdentifier)' != 'browser'" />

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:10

• WinZipAesKeyMaterial is declared with a trailing semicolon, which isn’t valid C# (C# doesn’t support forward-declaring structs). Browser builds will fail to compile this file.

{
internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:786

• In this AES update-mode branch, int keySizeBits = GetAesKeySizeBits(Encryption); (a few lines above) is assigned but never used. If warnings are treated as errors, this will break the build; if the call is only for validation, discard the value explicitly.

 // The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(
baseStream: _archive.ArchiveStream,

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1078

• This browser-only test validates ZipCrypto decryption, but it doesn’t cover creating a ZipCrypto entry on browser. Since this PR changes the ZipCrypto encryption path (header salt generation + password buffer clearing), adding a round-trip create/read assertion here would help prevent regressions.

 using MemoryStream createStream = new();
ZipArchive createArchive = await CreateZipArchive(async, createStream, ZipArchiveMode.Create, leaveOpen: true);
Assert.Throws<PlatformNotSupportedException>(() => createArchive.CreateEntry("aes.txt", Password, ZipEncryptionMethod.Aes256));
await DisposeZipArchive(async, createArchive);
}

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs:626

• ReadEncryptionSaltIfNeeded now returns early on browser/wasi without populating _aesSalt. In the sync open path (WrapWithDecryptionIfNeeded), AES entries first check _aesSalt is null and throw InvalidDataException(SR.LocalFileHeaderCorrupt), so on browser/wasi this can surface as “corrupt header” instead of the intended PlatformNotSupportedException for WinZip AES. Consider setting a non-null sentinel salt on browser/wasi so the open path reaches the WinZipAesStream stubs and throws PNSE consistently.

 if (!IsAesEncrypted || !_originallyInArchive || OperatingSystem.IsBrowser() || OperatingSystem.IsWasi())
{
return;
}

[alinpahontu2912]

/ba-g failure unrelated to my change

[Copilot]

Fixes#130650
which is regression from #122093

Using ZipArchive on browser-wasm unnecessarily retained System.Security.Cryptography, increasing trimmed application size even though WinZip AES is unsupported there.

Changes

• Exclude WinZip AES implementation files and the cryptography project reference from browser builds.
• Provide browser-specific WinZip AES stubs that continue throwing PlatformNotSupportedException.
• Keep ZipCrypto supported by removing its cryptography dependency:
  • Generate header randomness with Guid.NewGuid().
  • Clear pooled password buffers with Array.Clear.
• Add coverage ensuring browser ZipCrypto remains functional and the wasm dependency closure excludes System.Security.Cryptography.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
12 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 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot was unable to review this pull request because there is no eligible user to bill. To allow Copilot reviews on bot-authored pull requests, enable direct organization billing in your organization's Copilot settings.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1072

• This browser-only test validates ZipCrypto decryption, but this PR also changes browser behavior by swapping in WinZip AES stubs. Consider also asserting that opening the AES-encrypted entry in the same archive throws PlatformNotSupportedException, so the new stub path is exercised on Browser and regressions are caught.

 ZipArchiveEntry entry = archive.GetEntry("hello.txt");
Assert.NotNull(entry);
Assert.Equal(ZipEncryptionMethod.ZipCrypto, entry.EncryptionMethod);
using Stream entryStream = await OpenEntryStream(async, entry, Password);
using StreamReader reader = new(entryStream);

src/libraries/Common/src/Interop/Windows/BCrypt/Interop.BCryptGenRandom.GetRandomBytes.cs:30

• GetCryptographicallySecureRandomBytes currently forwards to GetRandomBytes, which throws InvalidOperationException on most failures. Since the method name (and the Unix implementation) implies cryptographic RNG semantics, it should throw CryptographicException for non-OOM failures to better match RandomNumberGenerator behavior.

 // BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG is always cryptographically secure.
internal static unsafe void GetCryptographicallySecureRandomBytes(byte* buffer, int length) =>
GetRandomBytes(buffer, length);

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:785

• keySizeBits is computed but never used in this AES update-mode path. This is dead code and can produce warnings / confusion; it should be removed (the key size was already baked into _derivedAesKeyMaterial).

 // Determine the actual compression method to use
// The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:9

• The WinZipAesKeyMaterial stub is declared as internal readonly struct WinZipAesKeyMaterial; which is not valid C# syntax (types can’t be forward-declared with a trailing semicolon). This will fail to compile on browser builds.

 internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System.IO.Compression.csproj:128

• System.Security.Cryptography doesn’t target $(NetCoreAppCurrent)-wasi (its csproj only includes windows/unix/android/apple/browser/$(NetCoreAppCurrent)), so keeping this ProjectReference for wasi will break the wasi build. The condition should exclude wasi as well as browser.

 <ProjectReference Include="$(LibrariesProjectRoot)System.Security.Cryptography\src\System.Security.Cryptography.csproj" Condition="'$(TargetPlatformIdentifier)' != 'browser'" />

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:10

• WinZipAesKeyMaterial is declared with a trailing semicolon, which isn’t valid C# (C# doesn’t support forward-declaring structs). Browser builds will fail to compile this file.

{
internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:786

• In this AES update-mode branch, int keySizeBits = GetAesKeySizeBits(Encryption); (a few lines above) is assigned but never used. If warnings are treated as errors, this will break the build; if the call is only for validation, discard the value explicitly.

 // The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(
baseStream: _archive.ArchiveStream,

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1078

• This browser-only test validates ZipCrypto decryption, but it doesn’t cover creating a ZipCrypto entry on browser. Since this PR changes the ZipCrypto encryption path (header salt generation + password buffer clearing), adding a round-trip create/read assertion here would help prevent regressions.

 using MemoryStream createStream = new();
ZipArchive createArchive = await CreateZipArchive(async, createStream, ZipArchiveMode.Create, leaveOpen: true);
Assert.Throws<PlatformNotSupportedException>(() => createArchive.CreateEntry("aes.txt", Password, ZipEncryptionMethod.Aes256));
await DisposeZipArchive(async, createArchive);
}

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs:626

• ReadEncryptionSaltIfNeeded now returns early on browser/wasi without populating _aesSalt. In the sync open path (WrapWithDecryptionIfNeeded), AES entries first check _aesSalt is null and throw InvalidDataException(SR.LocalFileHeaderCorrupt), so on browser/wasi this can surface as “corrupt header” instead of the intended PlatformNotSupportedException for WinZip AES. Consider setting a non-null sentinel salt on browser/wasi so the open path reaches the WinZipAesStream stubs and throws PNSE consistently.

 if (!IsAesEncrypted || !_originallyInArchive || OperatingSystem.IsBrowser() || OperatingSystem.IsWasi())
{
return;
}

[alinpahontu2912]

/ba-g failure unrelated to my change

[Copilot]

Fixes#130650
which is regression from #122093

Using ZipArchive on browser-wasm unnecessarily retained System.Security.Cryptography, increasing trimmed application size even though WinZip AES is unsupported there.

Changes

• Exclude WinZip AES implementation files and the cryptography project reference from browser builds.
• Provide browser-specific WinZip AES stubs that continue throwing PlatformNotSupportedException.
• Keep ZipCrypto supported by removing its cryptography dependency:
  • Generate header randomness with Guid.NewGuid().
  • Clear pooled password buffers with Array.Clear.
• Add coverage ensuring browser ZipCrypto remains functional and the wasm dependency closure excludes System.Security.Cryptography.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
12 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 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot was unable to review this pull request because there is no eligible user to bill. To allow Copilot reviews on bot-authored pull requests, enable direct organization billing in your organization's Copilot settings.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1072

• This browser-only test validates ZipCrypto decryption, but this PR also changes browser behavior by swapping in WinZip AES stubs. Consider also asserting that opening the AES-encrypted entry in the same archive throws PlatformNotSupportedException, so the new stub path is exercised on Browser and regressions are caught.

 ZipArchiveEntry entry = archive.GetEntry("hello.txt");
Assert.NotNull(entry);
Assert.Equal(ZipEncryptionMethod.ZipCrypto, entry.EncryptionMethod);
using Stream entryStream = await OpenEntryStream(async, entry, Password);
using StreamReader reader = new(entryStream);

src/libraries/Common/src/Interop/Windows/BCrypt/Interop.BCryptGenRandom.GetRandomBytes.cs:30

• GetCryptographicallySecureRandomBytes currently forwards to GetRandomBytes, which throws InvalidOperationException on most failures. Since the method name (and the Unix implementation) implies cryptographic RNG semantics, it should throw CryptographicException for non-OOM failures to better match RandomNumberGenerator behavior.

 // BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG is always cryptographically secure.
internal static unsafe void GetCryptographicallySecureRandomBytes(byte* buffer, int length) =>
GetRandomBytes(buffer, length);

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:785

• keySizeBits is computed but never used in this AES update-mode path. This is dead code and can produce warnings / confusion; it should be removed (the key size was already baked into _derivedAesKeyMaterial).

 // Determine the actual compression method to use
// The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:9

• The WinZipAesKeyMaterial stub is declared as internal readonly struct WinZipAesKeyMaterial; which is not valid C# syntax (types can’t be forward-declared with a trailing semicolon). This will fail to compile on browser builds.

 internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System.IO.Compression.csproj:128

• System.Security.Cryptography doesn’t target $(NetCoreAppCurrent)-wasi (its csproj only includes windows/unix/android/apple/browser/$(NetCoreAppCurrent)), so keeping this ProjectReference for wasi will break the wasi build. The condition should exclude wasi as well as browser.

 <ProjectReference Include="$(LibrariesProjectRoot)System.Security.Cryptography\src\System.Security.Cryptography.csproj" Condition="'$(TargetPlatformIdentifier)' != 'browser'" />

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:10

• WinZipAesKeyMaterial is declared with a trailing semicolon, which isn’t valid C# (C# doesn’t support forward-declaring structs). Browser builds will fail to compile this file.

{
internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:786

• In this AES update-mode branch, int keySizeBits = GetAesKeySizeBits(Encryption); (a few lines above) is assigned but never used. If warnings are treated as errors, this will break the build; if the call is only for validation, discard the value explicitly.

 // The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(
baseStream: _archive.ArchiveStream,

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1078

• This browser-only test validates ZipCrypto decryption, but it doesn’t cover creating a ZipCrypto entry on browser. Since this PR changes the ZipCrypto encryption path (header salt generation + password buffer clearing), adding a round-trip create/read assertion here would help prevent regressions.

 using MemoryStream createStream = new();
ZipArchive createArchive = await CreateZipArchive(async, createStream, ZipArchiveMode.Create, leaveOpen: true);
Assert.Throws<PlatformNotSupportedException>(() => createArchive.CreateEntry("aes.txt", Password, ZipEncryptionMethod.Aes256));
await DisposeZipArchive(async, createArchive);
}

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs:626

• ReadEncryptionSaltIfNeeded now returns early on browser/wasi without populating _aesSalt. In the sync open path (WrapWithDecryptionIfNeeded), AES entries first check _aesSalt is null and throw InvalidDataException(SR.LocalFileHeaderCorrupt), so on browser/wasi this can surface as “corrupt header” instead of the intended PlatformNotSupportedException for WinZip AES. Consider setting a non-null sentinel salt on browser/wasi so the open path reaches the WinZipAesStream stubs and throws PNSE consistently.

 if (!IsAesEncrypted || !_originallyInArchive || OperatingSystem.IsBrowser() || OperatingSystem.IsWasi())
{
return;
}

[alinpahontu2912]

/ba-g failure unrelated to my change

[Copilot]

Fixes#130650
which is regression from #122093

Using ZipArchive on browser-wasm unnecessarily retained System.Security.Cryptography, increasing trimmed application size even though WinZip AES is unsupported there.

Changes

• Exclude WinZip AES implementation files and the cryptography project reference from browser builds.
• Provide browser-specific WinZip AES stubs that continue throwing PlatformNotSupportedException.
• Keep ZipCrypto supported by removing its cryptography dependency:
  • Generate header randomness with Guid.NewGuid().
  • Clear pooled password buffers with Array.Clear.
• Add coverage ensuring browser ZipCrypto remains functional and the wasm dependency closure excludes System.Security.Cryptography.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
12 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 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot was unable to review this pull request because there is no eligible user to bill. To allow Copilot reviews on bot-authored pull requests, enable direct organization billing in your organization's Copilot settings.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1072

• This browser-only test validates ZipCrypto decryption, but this PR also changes browser behavior by swapping in WinZip AES stubs. Consider also asserting that opening the AES-encrypted entry in the same archive throws PlatformNotSupportedException, so the new stub path is exercised on Browser and regressions are caught.

 ZipArchiveEntry entry = archive.GetEntry("hello.txt");
Assert.NotNull(entry);
Assert.Equal(ZipEncryptionMethod.ZipCrypto, entry.EncryptionMethod);
using Stream entryStream = await OpenEntryStream(async, entry, Password);
using StreamReader reader = new(entryStream);

src/libraries/Common/src/Interop/Windows/BCrypt/Interop.BCryptGenRandom.GetRandomBytes.cs:30

• GetCryptographicallySecureRandomBytes currently forwards to GetRandomBytes, which throws InvalidOperationException on most failures. Since the method name (and the Unix implementation) implies cryptographic RNG semantics, it should throw CryptographicException for non-OOM failures to better match RandomNumberGenerator behavior.

 // BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG is always cryptographically secure.
internal static unsafe void GetCryptographicallySecureRandomBytes(byte* buffer, int length) =>
GetRandomBytes(buffer, length);

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:785

• keySizeBits is computed but never used in this AES update-mode path. This is dead code and can produce warnings / confusion; it should be removed (the key size was already baked into _derivedAesKeyMaterial).

 // Determine the actual compression method to use
// The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:9

• The WinZipAesKeyMaterial stub is declared as internal readonly struct WinZipAesKeyMaterial; which is not valid C# syntax (types can’t be forward-declared with a trailing semicolon). This will fail to compile on browser builds.

 internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System.IO.Compression.csproj:128

• System.Security.Cryptography doesn’t target $(NetCoreAppCurrent)-wasi (its csproj only includes windows/unix/android/apple/browser/$(NetCoreAppCurrent)), so keeping this ProjectReference for wasi will break the wasi build. The condition should exclude wasi as well as browser.

 <ProjectReference Include="$(LibrariesProjectRoot)System.Security.Cryptography\src\System.Security.Cryptography.csproj" Condition="'$(TargetPlatformIdentifier)' != 'browser'" />

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:10

• WinZipAesKeyMaterial is declared with a trailing semicolon, which isn’t valid C# (C# doesn’t support forward-declaring structs). Browser builds will fail to compile this file.

{
internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:786

• In this AES update-mode branch, int keySizeBits = GetAesKeySizeBits(Encryption); (a few lines above) is assigned but never used. If warnings are treated as errors, this will break the build; if the call is only for validation, discard the value explicitly.

 // The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(
baseStream: _archive.ArchiveStream,

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1078

• This browser-only test validates ZipCrypto decryption, but it doesn’t cover creating a ZipCrypto entry on browser. Since this PR changes the ZipCrypto encryption path (header salt generation + password buffer clearing), adding a round-trip create/read assertion here would help prevent regressions.

 using MemoryStream createStream = new();
ZipArchive createArchive = await CreateZipArchive(async, createStream, ZipArchiveMode.Create, leaveOpen: true);
Assert.Throws<PlatformNotSupportedException>(() => createArchive.CreateEntry("aes.txt", Password, ZipEncryptionMethod.Aes256));
await DisposeZipArchive(async, createArchive);
}

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs:626

• ReadEncryptionSaltIfNeeded now returns early on browser/wasi without populating _aesSalt. In the sync open path (WrapWithDecryptionIfNeeded), AES entries first check _aesSalt is null and throw InvalidDataException(SR.LocalFileHeaderCorrupt), so on browser/wasi this can surface as “corrupt header” instead of the intended PlatformNotSupportedException for WinZip AES. Consider setting a non-null sentinel salt on browser/wasi so the open path reaches the WinZipAesStream stubs and throws PNSE consistently.

 if (!IsAesEncrypted || !_originallyInArchive || OperatingSystem.IsBrowser() || OperatingSystem.IsWasi())
{
return;
}

[alinpahontu2912]

/ba-g failure unrelated to my change

[Copilot]

Fixes#130650
which is regression from #122093

Using ZipArchive on browser-wasm unnecessarily retained System.Security.Cryptography, increasing trimmed application size even though WinZip AES is unsupported there.

Changes

• Exclude WinZip AES implementation files and the cryptography project reference from browser builds.
• Provide browser-specific WinZip AES stubs that continue throwing PlatformNotSupportedException.
• Keep ZipCrypto supported by removing its cryptography dependency:
  • Generate header randomness with Guid.NewGuid().
  • Clear pooled password buffers with Array.Clear.
• Add coverage ensuring browser ZipCrypto remains functional and the wasm dependency closure excludes System.Security.Cryptography.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
12 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 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot was unable to review this pull request because there is no eligible user to bill. To allow Copilot reviews on bot-authored pull requests, enable direct organization billing in your organization's Copilot settings.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1072

• This browser-only test validates ZipCrypto decryption, but this PR also changes browser behavior by swapping in WinZip AES stubs. Consider also asserting that opening the AES-encrypted entry in the same archive throws PlatformNotSupportedException, so the new stub path is exercised on Browser and regressions are caught.

 ZipArchiveEntry entry = archive.GetEntry("hello.txt");
Assert.NotNull(entry);
Assert.Equal(ZipEncryptionMethod.ZipCrypto, entry.EncryptionMethod);
using Stream entryStream = await OpenEntryStream(async, entry, Password);
using StreamReader reader = new(entryStream);

src/libraries/Common/src/Interop/Windows/BCrypt/Interop.BCryptGenRandom.GetRandomBytes.cs:30

• GetCryptographicallySecureRandomBytes currently forwards to GetRandomBytes, which throws InvalidOperationException on most failures. Since the method name (and the Unix implementation) implies cryptographic RNG semantics, it should throw CryptographicException for non-OOM failures to better match RandomNumberGenerator behavior.

 // BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG is always cryptographically secure.
internal static unsafe void GetCryptographicallySecureRandomBytes(byte* buffer, int length) =>
GetRandomBytes(buffer, length);

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:785

• keySizeBits is computed but never used in this AES update-mode path. This is dead code and can produce warnings / confusion; it should be removed (the key size was already baked into _derivedAesKeyMaterial).

 // Determine the actual compression method to use
// The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:9

• The WinZipAesKeyMaterial stub is declared as internal readonly struct WinZipAesKeyMaterial; which is not valid C# syntax (types can’t be forward-declared with a trailing semicolon). This will fail to compile on browser builds.

 internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System.IO.Compression.csproj:128

• System.Security.Cryptography doesn’t target $(NetCoreAppCurrent)-wasi (its csproj only includes windows/unix/android/apple/browser/$(NetCoreAppCurrent)), so keeping this ProjectReference for wasi will break the wasi build. The condition should exclude wasi as well as browser.

 <ProjectReference Include="$(LibrariesProjectRoot)System.Security.Cryptography\src\System.Security.Cryptography.csproj" Condition="'$(TargetPlatformIdentifier)' != 'browser'" />

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:10

• WinZipAesKeyMaterial is declared with a trailing semicolon, which isn’t valid C# (C# doesn’t support forward-declaring structs). Browser builds will fail to compile this file.

{
internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:786

• In this AES update-mode branch, int keySizeBits = GetAesKeySizeBits(Encryption); (a few lines above) is assigned but never used. If warnings are treated as errors, this will break the build; if the call is only for validation, discard the value explicitly.

 // The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(
baseStream: _archive.ArchiveStream,

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1078

• This browser-only test validates ZipCrypto decryption, but it doesn’t cover creating a ZipCrypto entry on browser. Since this PR changes the ZipCrypto encryption path (header salt generation + password buffer clearing), adding a round-trip create/read assertion here would help prevent regressions.

 using MemoryStream createStream = new();
ZipArchive createArchive = await CreateZipArchive(async, createStream, ZipArchiveMode.Create, leaveOpen: true);
Assert.Throws<PlatformNotSupportedException>(() => createArchive.CreateEntry("aes.txt", Password, ZipEncryptionMethod.Aes256));
await DisposeZipArchive(async, createArchive);
}

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs:626

• ReadEncryptionSaltIfNeeded now returns early on browser/wasi without populating _aesSalt. In the sync open path (WrapWithDecryptionIfNeeded), AES entries first check _aesSalt is null and throw InvalidDataException(SR.LocalFileHeaderCorrupt), so on browser/wasi this can surface as “corrupt header” instead of the intended PlatformNotSupportedException for WinZip AES. Consider setting a non-null sentinel salt on browser/wasi so the open path reaches the WinZipAesStream stubs and throws PNSE consistently.

 if (!IsAesEncrypted || !_originallyInArchive || OperatingSystem.IsBrowser() || OperatingSystem.IsWasi())
{
return;
}

[alinpahontu2912]

/ba-g failure unrelated to my change

[Copilot]

Fixes#130650
which is regression from #122093

Using ZipArchive on browser-wasm unnecessarily retained System.Security.Cryptography, increasing trimmed application size even though WinZip AES is unsupported there.

Changes

• Exclude WinZip AES implementation files and the cryptography project reference from browser builds.
• Provide browser-specific WinZip AES stubs that continue throwing PlatformNotSupportedException.
• Keep ZipCrypto supported by removing its cryptography dependency:
  • Generate header randomness with Guid.NewGuid().
  • Clear pooled password buffers with Array.Clear.
• Add coverage ensuring browser ZipCrypto remains functional and the wasm dependency closure excludes System.Security.Cryptography.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
12 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 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot was unable to review this pull request because there is no eligible user to bill. To allow Copilot reviews on bot-authored pull requests, enable direct organization billing in your organization's Copilot settings.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1072

• This browser-only test validates ZipCrypto decryption, but this PR also changes browser behavior by swapping in WinZip AES stubs. Consider also asserting that opening the AES-encrypted entry in the same archive throws PlatformNotSupportedException, so the new stub path is exercised on Browser and regressions are caught.

 ZipArchiveEntry entry = archive.GetEntry("hello.txt");
Assert.NotNull(entry);
Assert.Equal(ZipEncryptionMethod.ZipCrypto, entry.EncryptionMethod);
using Stream entryStream = await OpenEntryStream(async, entry, Password);
using StreamReader reader = new(entryStream);

src/libraries/Common/src/Interop/Windows/BCrypt/Interop.BCryptGenRandom.GetRandomBytes.cs:30

• GetCryptographicallySecureRandomBytes currently forwards to GetRandomBytes, which throws InvalidOperationException on most failures. Since the method name (and the Unix implementation) implies cryptographic RNG semantics, it should throw CryptographicException for non-OOM failures to better match RandomNumberGenerator behavior.

 // BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG is always cryptographically secure.
internal static unsafe void GetCryptographicallySecureRandomBytes(byte* buffer, int length) =>
GetRandomBytes(buffer, length);

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:785

• keySizeBits is computed but never used in this AES update-mode path. This is dead code and can produce warnings / confusion; it should be removed (the key size was already baked into _derivedAesKeyMaterial).

 // Determine the actual compression method to use
// The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:9

• The WinZipAesKeyMaterial stub is declared as internal readonly struct WinZipAesKeyMaterial; which is not valid C# syntax (types can’t be forward-declared with a trailing semicolon). This will fail to compile on browser builds.

 internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System.IO.Compression.csproj:128

• System.Security.Cryptography doesn’t target $(NetCoreAppCurrent)-wasi (its csproj only includes windows/unix/android/apple/browser/$(NetCoreAppCurrent)), so keeping this ProjectReference for wasi will break the wasi build. The condition should exclude wasi as well as browser.

 <ProjectReference Include="$(LibrariesProjectRoot)System.Security.Cryptography\src\System.Security.Cryptography.csproj" Condition="'$(TargetPlatformIdentifier)' != 'browser'" />

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:10

• WinZipAesKeyMaterial is declared with a trailing semicolon, which isn’t valid C# (C# doesn’t support forward-declaring structs). Browser builds will fail to compile this file.

{
internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:786

• In this AES update-mode branch, int keySizeBits = GetAesKeySizeBits(Encryption); (a few lines above) is assigned but never used. If warnings are treated as errors, this will break the build; if the call is only for validation, discard the value explicitly.

 // The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(
baseStream: _archive.ArchiveStream,

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1078

• This browser-only test validates ZipCrypto decryption, but it doesn’t cover creating a ZipCrypto entry on browser. Since this PR changes the ZipCrypto encryption path (header salt generation + password buffer clearing), adding a round-trip create/read assertion here would help prevent regressions.

 using MemoryStream createStream = new();
ZipArchive createArchive = await CreateZipArchive(async, createStream, ZipArchiveMode.Create, leaveOpen: true);
Assert.Throws<PlatformNotSupportedException>(() => createArchive.CreateEntry("aes.txt", Password, ZipEncryptionMethod.Aes256));
await DisposeZipArchive(async, createArchive);
}

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs:626

• ReadEncryptionSaltIfNeeded now returns early on browser/wasi without populating _aesSalt. In the sync open path (WrapWithDecryptionIfNeeded), AES entries first check _aesSalt is null and throw InvalidDataException(SR.LocalFileHeaderCorrupt), so on browser/wasi this can surface as “corrupt header” instead of the intended PlatformNotSupportedException for WinZip AES. Consider setting a non-null sentinel salt on browser/wasi so the open path reaches the WinZipAesStream stubs and throws PNSE consistently.

 if (!IsAesEncrypted || !_originallyInArchive || OperatingSystem.IsBrowser() || OperatingSystem.IsWasi())
{
return;
}

[alinpahontu2912]

/ba-g failure unrelated to my change

[Copilot]

Fixes#130650
which is regression from #122093

Using ZipArchive on browser-wasm unnecessarily retained System.Security.Cryptography, increasing trimmed application size even though WinZip AES is unsupported there.

Changes

• Exclude WinZip AES implementation files and the cryptography project reference from browser builds.
• Provide browser-specific WinZip AES stubs that continue throwing PlatformNotSupportedException.
• Keep ZipCrypto supported by removing its cryptography dependency:
  • Generate header randomness with Guid.NewGuid().
  • Clear pooled password buffers with Array.Clear.
• Add coverage ensuring browser ZipCrypto remains functional and the wasm dependency closure excludes System.Security.Cryptography.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
12 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 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot was unable to review this pull request because there is no eligible user to bill. To allow Copilot reviews on bot-authored pull requests, enable direct organization billing in your organization's Copilot settings.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1072

• This browser-only test validates ZipCrypto decryption, but this PR also changes browser behavior by swapping in WinZip AES stubs. Consider also asserting that opening the AES-encrypted entry in the same archive throws PlatformNotSupportedException, so the new stub path is exercised on Browser and regressions are caught.

 ZipArchiveEntry entry = archive.GetEntry("hello.txt");
Assert.NotNull(entry);
Assert.Equal(ZipEncryptionMethod.ZipCrypto, entry.EncryptionMethod);
using Stream entryStream = await OpenEntryStream(async, entry, Password);
using StreamReader reader = new(entryStream);

src/libraries/Common/src/Interop/Windows/BCrypt/Interop.BCryptGenRandom.GetRandomBytes.cs:30

• GetCryptographicallySecureRandomBytes currently forwards to GetRandomBytes, which throws InvalidOperationException on most failures. Since the method name (and the Unix implementation) implies cryptographic RNG semantics, it should throw CryptographicException for non-OOM failures to better match RandomNumberGenerator behavior.

 // BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG is always cryptographically secure.
internal static unsafe void GetCryptographicallySecureRandomBytes(byte* buffer, int length) =>
GetRandomBytes(buffer, length);

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:785

• keySizeBits is computed but never used in this AES update-mode path. This is dead code and can produce warnings / confusion; it should be removed (the key size was already baked into _derivedAesKeyMaterial).

 // Determine the actual compression method to use
// The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:9

• The WinZipAesKeyMaterial stub is declared as internal readonly struct WinZipAesKeyMaterial; which is not valid C# syntax (types can’t be forward-declared with a trailing semicolon). This will fail to compile on browser builds.

 internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System.IO.Compression.csproj:128

• System.Security.Cryptography doesn’t target $(NetCoreAppCurrent)-wasi (its csproj only includes windows/unix/android/apple/browser/$(NetCoreAppCurrent)), so keeping this ProjectReference for wasi will break the wasi build. The condition should exclude wasi as well as browser.

 <ProjectReference Include="$(LibrariesProjectRoot)System.Security.Cryptography\src\System.Security.Cryptography.csproj" Condition="'$(TargetPlatformIdentifier)' != 'browser'" />

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/libraries/System.IO.Compression/src/System/IO/Compression/WinZipAes.PlatformNotSupported.cs:10

• WinZipAesKeyMaterial is declared with a trailing semicolon, which isn’t valid C# (C# doesn’t support forward-declaring structs). Browser builds will fail to compile this file.

{
internal readonly struct WinZipAesKeyMaterial;

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs:786

• In this AES update-mode branch, int keySizeBits = GetAesKeySizeBits(Encryption); (a few lines above) is assigned but never used. If warnings are treated as errors, this will break the build; if the call is only for validation, discard the value explicitly.

 // The AES extra field stores the real compression method
bool useDeflate = _compressionLevel != CompressionLevel.NoCompression;
Stream encryptionStream = WinZipAesStream.Create(
baseStream: _archive.ArchiveStream,

src/libraries/System.IO.Compression/tests/ZipArchive/zip_ReadTests.cs:1078

• This browser-only test validates ZipCrypto decryption, but it doesn’t cover creating a ZipCrypto entry on browser. Since this PR changes the ZipCrypto encryption path (header salt generation + password buffer clearing), adding a round-trip create/read assertion here would help prevent regressions.

 using MemoryStream createStream = new();
ZipArchive createArchive = await CreateZipArchive(async, createStream, ZipArchiveMode.Create, leaveOpen: true);
Assert.Throws<PlatformNotSupportedException>(() => createArchive.CreateEntry("aes.txt", Password, ZipEncryptionMethod.Aes256));
await DisposeZipArchive(async, createArchive);
}

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs:626

• ReadEncryptionSaltIfNeeded now returns early on browser/wasi without populating _aesSalt. In the sync open path (WrapWithDecryptionIfNeeded), AES entries first check _aesSalt is null and throw InvalidDataException(SR.LocalFileHeaderCorrupt), so on browser/wasi this can surface as “corrupt header” instead of the intended PlatformNotSupportedException for WinZip AES. Consider setting a non-null sentinel salt on browser/wasi so the open path reaches the WinZipAesStream stubs and throws PNSE consistently.

 if (!IsAesEncrypted || !_originallyInArchive || OperatingSystem.IsBrowser() || OperatingSystem.IsWasi())
{
return;
}

[alinpahontu2912]

/ba-g failure unrelated to my change