2. Apache policy, as I understand it, does allow images in source releases. Not sure about .min.js, but it isn’t binary.
I voted -1 because the release does not comply with policy. This isn’t the place to debate policy. (I am glad to see you weighed in on https://issues.apache.org/jira/browse/LEGAL-288 <https://issues.apache.org/jira/browse/LEGAL-288>; if you want to change policy, you could also consider posting to legal-discuss@. 3. Since the source release mirrors what is in source control, it is a reasonable expectation that the release process does not modify what is in source control. It is also reasonable that when I browse the source in GitHub I should see the same LICENSE file that will be in the source release. I don’t think there’s any requirement or expectation that the release plugin should do the same for source and binary releases. (Technically there are no binary releases, just artifacts.) Making an artifact is a more complex process than creating a source tarball, involving downloading dependencies from Maven central etc., and so it makes sense that the license is also generated based on those artifacts. Julian > On Apr 8, 2021, at 12:56 AM, Vladimir Sitnikov <[email protected]> > wrote: > > Julian>2. Regarding gradle-wrapper.jar. Yes, it affects Calcite too > > Removal of gradle-wrapper.jar creates problems, and it solves no real > issues. > > Just in case, if you are to forbid binary files in the source release, then > please clarify why do you allow > the following binary files in the source release: > > /favicon.ico > /site/img/feather.png > /site/img/logo.png > /site/js/html5shiv.min.js > /site/js/respond.min.js > > ^^^ the above is not a joke. The files are binary, it is hard to verify if > they contain backdoors or security issues. > I literally can't tell if logo.png could hack a preview app in my OS. > I can't re-create logo.png from text-like human-readable sources. > > Forsing users to do download Gradle manually makes it way harder to build > Calcite (they would have to track the exact version). > Even in the case users would download the proper Gradle version manually, > they might miss verifying the integrity, > so removal of gradle-wrapper.jar opens a possibility for supply-chain > attacks (currently the wrapper is verified, and it verifies the retrieved > Gradle). > Automatic retrieval of gradle-wrapper.jar is hard to do in a secure manner. > In case you missed it, Maven Wrapper did NOT verify the retrieved jar. > > At the same time, gradle-wrapper.jar can be verified: > 1. There are the official checksums > 2. Users can build their own gradle-wrapper.jar (e.g. from Gradle sources) > and ensure the resulting jar matches exactly what is included in the release > > In other words, the inclusion of gradle-wrapper.jar makes it significantly > more secure and easier to operate for the consumers. > The ones who have a fear of jar files can unpack tar.gz and delete all the > jars if any. > > Julian> My opinion is that neither the release plugin (nor the release > manager) should be modifying source files. > > What do you suggest for the case when binary and source releases have > different contents due to a different set of the embedded third-party > dependencies? > > Vladimir
