Migrate to zlib-ng, part 1: copy source code only

[carlossanlop]

Contributes to #101465

As requested in the original PR, to make reviewing easier, I am submitting this separate PR that copies the zlib-ng source code and updates the licensing files, but without consuming it in runtime yet.

[dotnet-policy-service]

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

[jkoritzinsky]

LGTM as long as all changes to zlib-ng are captured in zlib-ng-version.txt.

[carlossanlop]

@jkotas I have a question about your comment in the other PR:

The test binaries like src/native/external/zlib-ng/test/CVE-2002-0059/test.gz are going to pain to deal with for source build.

Can we exclude the test subdirectory from the vendored copy? I do not expect that we are going to run the native zlib-ng tests in this repo.

For my own education, why would this cause problems?

[jkoritzinsky]

Source-build has issues with introducing binary files into the repo. There's a whole process that needs to be done to make sure that they're not introduced into the final product in any way (including having the source-build build itself remove the files from disk before starting). It's easier if we don't have the binaries in the first place.

[carlossanlop]

Contributes to #101465

As requested in the original PR, to make reviewing easier, I am submitting this separate PR that copies the zlib-ng source code and updates the licensing files, but without consuming it in runtime yet.

[dotnet-policy-service]

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

[jkoritzinsky]

LGTM as long as all changes to zlib-ng are captured in zlib-ng-version.txt.

[carlossanlop]

@jkotas I have a question about your comment in the other PR:

The test binaries like src/native/external/zlib-ng/test/CVE-2002-0059/test.gz are going to pain to deal with for source build.

Can we exclude the test subdirectory from the vendored copy? I do not expect that we are going to run the native zlib-ng tests in this repo.

For my own education, why would this cause problems?

[jkoritzinsky]

Source-build has issues with introducing binary files into the repo. There's a whole process that needs to be done to make sure that they're not introduced into the final product in any way (including having the source-build build itself remove the files from disk before starting). It's easier if we don't have the binaries in the first place.

[carlossanlop]

Contributes to #101465

As requested in the original PR, to make reviewing easier, I am submitting this separate PR that copies the zlib-ng source code and updates the licensing files, but without consuming it in runtime yet.

[dotnet-policy-service]

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

[jkoritzinsky]

LGTM as long as all changes to zlib-ng are captured in zlib-ng-version.txt.

[carlossanlop]

@jkotas I have a question about your comment in the other PR:

The test binaries like src/native/external/zlib-ng/test/CVE-2002-0059/test.gz are going to pain to deal with for source build.

Can we exclude the test subdirectory from the vendored copy? I do not expect that we are going to run the native zlib-ng tests in this repo.

For my own education, why would this cause problems?

[jkoritzinsky]

Source-build has issues with introducing binary files into the repo. There's a whole process that needs to be done to make sure that they're not introduced into the final product in any way (including having the source-build build itself remove the files from disk before starting). It's easier if we don't have the binaries in the first place.

[carlossanlop]

Contributes to #101465

As requested in the original PR, to make reviewing easier, I am submitting this separate PR that copies the zlib-ng source code and updates the licensing files, but without consuming it in runtime yet.

[dotnet-policy-service]

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

[jkoritzinsky]

LGTM as long as all changes to zlib-ng are captured in zlib-ng-version.txt.

[carlossanlop]

@jkotas I have a question about your comment in the other PR:

The test binaries like src/native/external/zlib-ng/test/CVE-2002-0059/test.gz are going to pain to deal with for source build.

Can we exclude the test subdirectory from the vendored copy? I do not expect that we are going to run the native zlib-ng tests in this repo.

For my own education, why would this cause problems?

[jkoritzinsky]

Source-build has issues with introducing binary files into the repo. There's a whole process that needs to be done to make sure that they're not introduced into the final product in any way (including having the source-build build itself remove the files from disk before starting). It's easier if we don't have the binaries in the first place.

[carlossanlop]

Contributes to #101465

As requested in the original PR, to make reviewing easier, I am submitting this separate PR that copies the zlib-ng source code and updates the licensing files, but without consuming it in runtime yet.

[dotnet-policy-service]

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

[jkoritzinsky]

LGTM as long as all changes to zlib-ng are captured in zlib-ng-version.txt.

[carlossanlop]

@jkotas I have a question about your comment in the other PR:

The test binaries like src/native/external/zlib-ng/test/CVE-2002-0059/test.gz are going to pain to deal with for source build.

Can we exclude the test subdirectory from the vendored copy? I do not expect that we are going to run the native zlib-ng tests in this repo.

For my own education, why would this cause problems?

[jkoritzinsky]

Source-build has issues with introducing binary files into the repo. There's a whole process that needs to be done to make sure that they're not introduced into the final product in any way (including having the source-build build itself remove the files from disk before starting). It's easier if we don't have the binaries in the first place.

[carlossanlop]

Contributes to #101465

As requested in the original PR, to make reviewing easier, I am submitting this separate PR that copies the zlib-ng source code and updates the licensing files, but without consuming it in runtime yet.

[dotnet-policy-service]

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

[jkoritzinsky]

LGTM as long as all changes to zlib-ng are captured in zlib-ng-version.txt.

[carlossanlop]

@jkotas I have a question about your comment in the other PR:

The test binaries like src/native/external/zlib-ng/test/CVE-2002-0059/test.gz are going to pain to deal with for source build.

Can we exclude the test subdirectory from the vendored copy? I do not expect that we are going to run the native zlib-ng tests in this repo.

For my own education, why would this cause problems?

[jkoritzinsky]

Source-build has issues with introducing binary files into the repo. There's a whole process that needs to be done to make sure that they're not introduced into the final product in any way (including having the source-build build itself remove the files from disk before starting). It's easier if we don't have the binaries in the first place.

[carlossanlop]

Contributes to #101465

As requested in the original PR, to make reviewing easier, I am submitting this separate PR that copies the zlib-ng source code and updates the licensing files, but without consuming it in runtime yet.

[dotnet-policy-service]

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

[jkoritzinsky]

LGTM as long as all changes to zlib-ng are captured in zlib-ng-version.txt.

[carlossanlop]

@jkotas I have a question about your comment in the other PR:

The test binaries like src/native/external/zlib-ng/test/CVE-2002-0059/test.gz are going to pain to deal with for source build.

Can we exclude the test subdirectory from the vendored copy? I do not expect that we are going to run the native zlib-ng tests in this repo.

For my own education, why would this cause problems?

[jkoritzinsky]

Source-build has issues with introducing binary files into the repo. There's a whole process that needs to be done to make sure that they're not introduced into the final product in any way (including having the source-build build itself remove the files from disk before starting). It's easier if we don't have the binaries in the first place.

[carlossanlop]

Contributes to #101465

As requested in the original PR, to make reviewing easier, I am submitting this separate PR that copies the zlib-ng source code and updates the licensing files, but without consuming it in runtime yet.

[dotnet-policy-service]

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

[jkoritzinsky]

LGTM as long as all changes to zlib-ng are captured in zlib-ng-version.txt.

[carlossanlop]

@jkotas I have a question about your comment in the other PR:

The test binaries like src/native/external/zlib-ng/test/CVE-2002-0059/test.gz are going to pain to deal with for source build.

Can we exclude the test subdirectory from the vendored copy? I do not expect that we are going to run the native zlib-ng tests in this repo.

For my own education, why would this cause problems?

[jkoritzinsky]

Source-build has issues with introducing binary files into the repo. There's a whole process that needs to be done to make sure that they're not introduced into the final product in any way (including having the source-build build itself remove the files from disk before starting). It's easier if we don't have the binaries in the first place.