On Wed, 4 Sep 2019 at 13:24, Vladimir Sitnikov <[email protected]> wrote: > > sebb>jars were correctly downloaded > > Oh. I thought it was there to prevent man-in-the-middle.
Same thing - the hash will detect if the contents is different. > AFAIK, Gradle automatically uses SHA1 for dependencies it downloads from > Maven Central. Where does it get the SHA1 values? > I think the only exception in our case is darcula.jar which is not > available on Central, so Gradle can't verify if the file is ok or not. > > sebb>However using PGP to check downloaded jars means users have to install > sebb>pgp and fetch the KEYS. > > The PR uses Bouncy Castle Java library to perform PGP verification, so it > does not depend on the platform-native PGP implementation. > The keys are downloaded automatically as well. > > So there's no extra work for the end users. I see. > Well PR the code does not use KEYS file from apache.org. It uses key ids > that are specified in checksum.xml file. > However, current state of KEYS at apache.org leaves much to be desired, so > automatic verification against apache.org is not possible at the moment > anyway. > > sebb>Also using the PGP key would not distinguish the case where different > sebb>versions of the jar have the same name > > I do not see why is that important. > Current build process does not rely on jar names. Does the build process always download all the files? That seems rather inefficient. Surely it checks whether there is already a local copy? In which case, if there can be multiple versions with the same name, then the PGP key might not be sufficient to distinguish them. > On the other hand, Gradle uses dependency coordinates (e.g. > group:module:version:classifier@extension + a bunch of other properties > like "repository URL") to distinguish dependency artifacts, > so even if multiple versions could have the same filename Gradle should > provide the proper content for a requested version. Only if the download source actually distinguishes these things. Maven does do so, but there have been JMeter dependencies not in Maven where that was not necessarily true. As I wrote, it's unlikely, but it's not impossible. > Vladimir
