Hey Yonik, Thank you for the feedback.
Regarding the following: > I'm seeing a lot of extraneous files in the release candidate... it > looks like maybe the working directory was tarred up after testing? > For some files, this can make it tough to tell what is actually a > source file and what is just a derived file. > It's also error prone to tar up a development directory since one > can't guarantee that all of the tested files are in source control. > > Some examples of the extra files: > ./integration > ./integration/Cargo.toml > ./integration/local_data_272627079782518201974418350628471215361 > ./integration/local_data_272627079782518201974418350628471215361/runtime > ./integration/local_data_272627079782518201974418350628471215361/runtime/._current_config.toml > ./integration/local_data_272627079782518201974418350628471215361/runtime/current_config.toml > ./integration/local_data_272627079782518201974418350628471215361/state/log > .[...] > > From a security perspective, a binary file masquerading as a test file > was how the xz backdoor got introduced ;-) > https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know > > Also note the Apple-specific ._ files everywhere. This makes it > difficult to even do something like find . -name \*.rs > Another nit is that the archive was not contained in a directory (e.g. > tar xvzf iggy.gz spewed a bunch of files in my CWD) Could be, that when building the artifact, some of the files from running the integration tests weren't cleaned up properly (all this temp local_data directories). As for the Apple specific files, we'll make sure to build artifact always on Linux, to avoid any confusion. And we'll also move all the files into the root directory, as suggested. > Regarding licenses: I see these files: > ./licenses > ./licenses/ring-BoringSSL.txt > ./licenses/passterm-BSD 3-Clause.txt > > Is there source code using these licenses included in the > distribution? If so, I think the top-level LICENSE file may need to > reflect that. > https://infra.apache.org/licensing-howto.html As you can see in the dependencies.md file, there are just a few libraries that we use (from crates.io), which do not have Apache 2.0 / MIT (or similar) license, thus we explicitly added these licenses to this directory. We do not publish the source code of these libraries as part of the artifact (these are just used to build the project as the external dependency). Should we somehow reflect this in the release artifact, or maybe we don't need these licenses directory to be published at all? --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
