PGP-based dependency verification

[Vladimir Sitnikov <si...@gmail.com>]

Hi,

What do you think of https://github.com/apache/jmeter/pull/488 ?

It enables to use PGP for artifact verification, so it would simplify
dependency updates without loosing too much.

For instance, recent Jackson and Apache Tika updates could have been served
by
<trusted-key id='c9fbaa83a8753994' group='com.fasterxml.jackson.core' />
and
<trusted-key id='4a51a45b944ffd51' group='org.apache.tika' />

Vladimir

Re: Current state of keys at apache.org (was: PGP-based dependency verification)

[sebb <se...@gmail.com>]

On Wed, 4 Sep 2019 at 13:59, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> sebb>Can you provide some examples?
>
> 1) META files are often missing.
> For instance: https://www.apache.org/dist/commons/ ,
> https://www.apache.org/dist/httpcomponents/ ,
> https://www.apache.org/dist/logging/ , https://www.apache.org/dist/tika/  ,
> https://www.apache.org/dist/xalan/ , https://www.apache.org/dist/xerces/,
> https://www.apache.org/dist/groovy/, https://www.apache.org/dist/geronimo/ and
> so on.
>
> 2) META files do not describe "who signs Nexus artifacts". In other words,
> it would be nice if META files could specify that "official JMeter jars
> should be signed by ..."
> Current file https://www.apache.org/dist/jmeter/META lists just "binaries/"
> and "sources/", and there's no room for "who signs org.apache.jmeter Maven
> artifacts".

So it's not actually a problem with KEYS files.

AIUI META files were introduced to the ASF fairly recently, and there
has been almost no promotion of their use. I think they were set up by
Henk Penning, who has sadly since passed.

If you wish to help progress them, I suggest you contact
usesr@infra.a.o and/or raise an INFRA JIRA.

AFAICT the ASF META files won't help with checking 3rd party dependencies.

> I do understand that "Maven jars" are convenience-only, however it is
> really sad we use 30 or so different Apache dependencies via Maven jars,
> and we don't really know which PGP keys should we trust.

In which case, I suggest you contact ASF Infra as noted above.

> Vladimir

Re: Current state of keys at apache.org (was: PGP-based dependency verification)

[Vladimir Sitnikov <si...@gmail.com>]

sebb>Can you provide some examples?

1) META files are often missing.
For instance: https://www.apache.org/dist/commons/ ,
https://www.apache.org/dist/httpcomponents/ ,
https://www.apache.org/dist/logging/ , https://www.apache.org/dist/tika/  ,
https://www.apache.org/dist/xalan/ , https://www.apache.org/dist/xerces/,
https://www.apache.org/dist/groovy/, https://www.apache.org/dist/geronimo/ and
so on.

2) META files do not describe "who signs Nexus artifacts". In other words,
it would be nice if META files could specify that "official JMeter jars
should be signed by ..."
Current file https://www.apache.org/dist/jmeter/META lists just "binaries/"
and "sources/", and there's no room for "who signs org.apache.jmeter Maven
artifacts".
I do understand that "Maven jars" are convenience-only, however it is
really sad we use 30 or so different Apache dependencies via Maven jars,
and we don't really know which PGP keys should we trust.

Vladimir

Current state of keys at apache.org (was: PGP-based dependency verification)

[sebb <se...@gmail.com>]

On Wed, 4 Sep 2019 at 13:24, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> 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.

What do you mean by that?

Can you provide some examples?

Sebb.

Re: PGP-based dependency verification

[Vladimir Sitnikov <si...@gmail.com>]

Philippe>An additional question, can you confirm that libraries that were
not signed
Philippe>with PGP key can still be used ?

Yes. There's always an option to use "SHA only" even if PGP signature is
present.
As of now, Gradle Plugin Portal forbids publishing of `.asc` signatures
(for unknown reason),
so virtually all Gradle plugins come without PGP.

Philippe>For those, we rely on SHA right ?

You are right, those are verified with SHA-512.

The only forbidden case is to omit both SHA and PGP. So there should be at
least something.

Vladimir

Re: PGP-based dependency verification

[Philippe Mouawad <ph...@gmail.com>]

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 <
sitnikov.vladimir@gmail.com> 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.

Re: PGP-based dependency verification

[Vladimir Sitnikov <si...@gmail.com>]

>It uses its own folder structure that uses different files even for the
case when different repositories have different content for the very same
artifact version.

Just in case, here's relevant section in Gradle documentation:
https://docs.gradle.org/current/userguide/dependency_cache.html#header

In case you missed it, I've created a blogpost on the need for PGP in
dependency verification:
https://medium.com/@vladimirsitniko/dependency-verification-checksum-vs-pgp-582e76207019

Vladimir

Re: PGP-based dependency verification

[Vladimir Sitnikov <si...@gmail.com>]

sebb>Where does it get the SHA1 values?

From Maven Central.
Sonatype repository requires all artifacts to have SHA1 and PGP.

sebb>Does the build process always download all the files?

Gradle has resolution cache, so it does not download dependencies on each
build.
It uses its own folder structure that uses different files even for the
case when different repositories have different content for the very same
artifact version.

sebb>Surely it checks whether there is already a local copy?

We rely on Gradle to resolve dependencies, and it does that just fine.
It does not suffer from "different artifacts have the same filename" issue.

Local file location is like
$HOME/.gradle/caches/modules-2/files-2.1/com.squareup.okio/okio/2.2.2/36f483536153f15339a8b48d508e22be7c9c531a/okio-2.2.2.jar

36f483536153f15339a8b48d508e22be7c9c531a is SHA1 of the file contents.

sebb>Maven does do so, but there have been JMeter dependencies not in Maven
where that was not necessarily true

To my best knowledge the current build script never uses file names to
cache information.
We always use artifact ids, and we rely on Gradle's dependency cache, so
the issue you mention is indeed impossible.

Vladimir

Re: PGP-based dependency verification

[sebb <se...@gmail.com>]

On Wed, 4 Sep 2019 at 13:24, Vladimir Sitnikov
<si...@gmail.com> 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

Re: PGP-based dependency verification

[Vladimir Sitnikov <si...@gmail.com>]

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

Re: PGP-based dependency verification

[sebb <se...@gmail.com>]

On Tue, 3 Sep 2019 at 19:36, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> >but isn't it a bit different in semantics to
> >the current checksum based validation?
>
> Exactly. It is a different semantics.
> The case here is I do not know the intention behind use of SHA-512 in
> JMeter build.

As I recall, MD5 hashes of jars were originally added to ensure that
the jars were correctly downloaded.
There may also have been some cases where different versions of jars
did not have different names.

> >Do you think this is a problem?
>
> I'm inclined that PGP is good enough.
> For instance, JMeter publishes 20 or so jars to Nexus, and we never publish
> "the official" SHA-512 checksums.

AFAIK, that's only because Nexus does not yet support SHA-512.
There are plans to enable that.

> >but isn't it a bit different in semantics
>
> There's yet another option: we could use both PGP+SHA for verification.
> It won't make dependency updates easier, however it would simplify review.

However using PGP to check downloaded jars means users have to install
pgp and fetch the KEYS.

This is additional work for users.

Also using the PGP key would not distinguish the case where different
versions of the jar have the same name.
I agree it's not likely, but it's also not impossible.

Using the key is a neat idea, but I don't think the advantages
outweigh the disadvantages.

> Vladimir

Re: PGP-based dependency verification

[Vladimir Sitnikov <si...@gmail.com>]

>but isn't it a bit different in semantics to
>the current checksum based validation?

Exactly. It is a different semantics.
The case here is I do not know the intention behind use of SHA-512 in
JMeter build.

>Do you think this is a problem?

I'm inclined that PGP is good enough.
For instance, JMeter publishes 20 or so jars to Nexus, and we never publish
"the official" SHA-512 checksums.

>but isn't it a bit different in semantics

There's yet another option: we could use both PGP+SHA for verification.
It won't make dependency updates easier, however it would simplify review.

Vladimir

Re: PGP-based dependency verification

[Felix Schumacher <fe...@internetallee.de>]

Am 03.09.19 um 12:02 schrieb Vladimir Sitnikov:
> Hi,
>
> What do you think of https://github.com/apache/jmeter/pull/488 ?


I think it is a nice idea, but isn't it a bit different in semantics to
the current checksum based validation?

At the moment we check for the exact version of the binary, while with
pgp based validation we would check for an exact version released by the
owner of the key.

Do you think this is a problem? On the other hand I trust that mechanism
all the time for my ubuntu distro and it would be the same for windows,
BSD and all the others, right?

Felix

>
> It enables to use PGP for artifact verification, so it would simplify
> dependency updates without loosing too much.
>
> For instance, recent Jackson and Apache Tika updates could have been served
> by
> <trusted-key id='c9fbaa83a8753994' group='com.fasterxml.jackson.core' />
> and
> <trusted-key id='4a51a45b944ffd51' group='org.apache.tika' />
>
> Vladimir
>