Vote on RC1. The mvnw jar file was removed. Including the mvnw jar was a change from previous releases. Other binary files have been in previous releases since they are needed to build/test Calcite.
Kevin Risden On Mon, Mar 18, 2019 at 11:58 AM Andrei Sereda <and...@sereda.cc> wrote: > Hello, > > Can one vote on RC 1 (separate thread) or should we wait on decision > wherever having jar files in calcite source distribution is acceptable ? > > On Fri, Mar 15, 2019 at 4:08 PM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > Julian> Lastly, this .jar file is non-essential. The release builds > > just fine without it. > > > > The use of consistent build tool versions would reduce risks. > > For instance: Maven 3.6.1-SNAPSHOT might happen to build Calcite "just > > fine" yet it could silently corrupt something. > > Then ./mvnw does not verify download integrity, so it makes > > build/release less secure. > > > > Why take those risks? > > How can I validate calcite.jar artifacts that are uploaded to Maven > > repository? Which tool could I use to validate that jars match the > > expected ones? > > Can I vote for source artifacts only and explicitly veto binary jars > > on a basis of "I can't validate wha's inside"? > > > > Even though Maven does not support wrapper natively, the case for > > wrapper would be even more important when we use Gradle. > > > > I see a couple of options: > > A) Include maven-wrapper.jar, and put its expected SHA256 side by > > side. We don't update the file often, so "IP and/or tampering" could > > be checked by verifying SHA for the jar file. > > > > B) We could include maven-wrapper in a source form and build it during > > the very first mvnw call. All the *.java files for maven-wrapper sum > > up to 70KiB which is just tiny. > > A single JdbcTest.jar is 350KiB. > > > > Any thoughts? > > ^^ The question above is quite real and I guess the answer would be > > pretty much reused for Gradle-based build. > > > > Julian> Since we have created them, and they are available nowhere else, > > they > > Julian> belong in the source release. > > > > I don't think we created fontawesome-webfont.ttf, did we? > > Technically speaking, calcite/site/fonts is 500+KiB which does look > > like binary files. > > > > Julian> Code is different. The textual source is editable, but the object > > Julian> files (in this case the .class files in the .jar) are not. > > > > As you know, "TrueType systems include a virtual machine that > > executes programs inside the font", so *.ttf is an object file. > > There are CVEs for TTF processing. > > > > Even though it might sound like a stretch, I don't quite buy "having > > consistent build system is not important" kind of conclusions. > > > > Vladimir > > >
