Hi,
@Vladimir, Thanks for your PR and proposal.

An additional question, can you confirm that libraries that were not signed
with PGP key can still be used ?
For those, we rely on SHA right ? That's what I understand from your PR,
but I want to be sure before voting.

Thanks

On Wed, Sep 4, 2019 at 2:24 PM Vladimir Sitnikov <
[email protected]> wrote:

> sebb>jars were correctly downloaded
>
> Oh. I thought it was there to prevent man-in-the-middle.
>
> AFAIK, Gradle automatically uses SHA1 for dependencies it downloads from
> Maven Central.
> 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.
>
> 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.
> 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.
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Reply via email to