signalapp / gradle-witness Goto Github PK

Is it possible to implement a verification system that garantees that the pgp-signatures (*.asc files) are still correct and that the pgp-signer is still the same?

The current implementation of gradle-witness verifies that the checksum of the lib is correct.

As a developer every time i whish to use a new lib version i have to update the checksum, too.

With the pinned-pgp-signer verification i can declare trust in the signer. there is no need to update the signature in the gralde file when there are version updates. update is only neccessary if the pgp-signer changes

Not sure if you guys use Jenkins internally, but I would love to see a version of this library for Jenkins plugins

http://www.benmccann.com/blog/how-to-take-over-the-computer-of-a-jenkins-user/

Feel free to close this issue if it's not something you're interested in. Just wanted to pass along the idea

When running gradle tasks --all it would be nice to see calculateChecksums under the "Verification Tasks" group and with a description.

Right now it is listed under "Other tasks" with no description:

...
Other tasks
-----------
calculateChecksums
...

With databinding enabled in Android project build.gradle, gradle-witness

data binding enabled via:

dataBinding {
    enabled = true
}

output is:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':vlc-android'.
> Failed to notify project evaluation listener.
   > No dependency for integrity assertion found: com.android.databinding:library
   > Cannot change dependencies of configuration ':vlc-android:compile' after it has been resolved.

This is a really nice idea here!
However, it seems that the sha256 calculation performed by the plugin is different than want I'm getting from OSX's shasum tool

➜  Signal-Android git:(feature/share_location) ✗ find . -name "*.jar" | grep gcm
./build/intermediates/exploded-aar/com.google.android.gms/play-services-gcm/8.1.0/jars/classes.jar
➜  Signal-Android git:(feature/share_location) ✗ shasum -a 256 ./build/intermediates/exploded-aar/com.google.android.gms/play-services-gcm/8.1.0/jars/classes.jar
ef311fb0a50b9cb5db171f914fa7d714292173bb8d789fa46686191ce47aadb6  ./build/intermediates/exploded-aar/com.google.android.gms/play-services-gcm/8.1.0/jars/classes.jar
➜  Signal-Android git:(feature/share_location) ✗ gradle -q calculateChecksums | grep gcm
Verifying com.google.android.gms:play-services-gcm
        'com.google.android.gms:play-services-gcm:757ecd2c837ac81c98f4cc7dc783e7454c6d0506f6cc66b10417126b675248c9',

When I add new dependency to my project and run calculateChecksums
Then git diff should show me minimal differences.

This can be achieved if dependencies are sorted by groupId and artifactName;

https://github.com/signalapp/gradle-witness/blob/master/src/main/groovy/org/whispersystems/witness/WitnessPlugin.groovy#L56

Since the whole gradle build process for Android relies on downloading plugins from jcenter, we really need a way to do what gradle-witness does, but for those plugins. @dschuermann already made it possible to have the gradle wrapper verify the sha256 of gradle binaries it downloads: gradle/gradle#448 The missing piece remains gradle plugins.

This is probably the most essential bit to verify:

        classpath 'com.android.tools.build:gradle:1.2.3'

I'd like to package this and include it in Debian. It would be best if there was an official "release" for gradle-witness that can then be packaged. That's trivial to do with github.com: just make a signed tag that marks the version, and push it to this repo. The Debian packaging can then get the source tarball from github directly.

With a project organized with several modules, I don't want to verify my own dependencies.
gradle-witness doesn't allow this.

When building Signal-Android, I'm getting signature verification failures, but when I try to recalculate the checksum, it fails on that same signature:

./gradlew -q calculateChecksums
signing.properties not found
Verifying me.leolin:ShortcutBadger
Verifying se.emilsjolander:stickylistheaders
Verifying com.google.android.gms:play-services-gcm
Verifying com.google.android.gms:play-services-maps
Verifying com.google.android.gms:play-services-location
Verifying com.jpardogo.materialtabstrip:library
Verifying org.w3c:smil
Verifying org.apache.httpcomponents:httpclient-android
Verifying com.github.chrisbanes.photoview:library
Verifying com.github.bumptech.glide:glide
Verifying com.makeramen:roundedimageview
Verifying com.pnikosis:materialish-progress
Verifying de.greenrobot:eventbus
Verifying pl.tajchert:waitingdots
Verifying com.soundcloud.android:android-crop
Verifying com.android.support:appcompat-v7

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'Signal-Android'.
> Checksum failed for com.android.support:appcompat-v7:4b5ccba8c4557ef04f99aa0a80f8aa7d50f05f926a709010a54afd5c878d3618

This would be as easy as taking the commit from https://github.com/akwizgran/gradle-witness.

Updating this dependency to support java-library would be more welcome than using a fork at my company, and probably everywhere else.

When applying the witness plugin I get this warning output:

Configure project :
The Task.leftShift(Closure) method has been deprecated and is scheduled to be removed in Gradle 5.0. Please use Task.doLast(Action) instead.

I'm happy to submit a pull request for this issue asap.

We'd love to use gradle-witness in Apache Aurora, but will need clarity on the license first. Obviously for us, an Apache License 2.0 compatible license would be ideal :-)

Gradle-witness only supports libraries added with "compile", but not "implementation".

WARNING: Configuration 'compile' is obsolete and has been replaced with 'implementation'.
It will be removed at the end of 2018

Correct me if I'm wrong, but I don't think the pom/transient dependencies are verified. A malicious repo could edit a pom, add a new transient dependency without triggering a verification failure. The newly created dependency will not exist in the dependencyVerification block and therefore not be checked.

The pom (or some transient dependency list) would need to also be verified, not just the jar files.

I've been thinking about using Blockchain-based technology -- I'm looking at using Namecoin for a proof-of-concept implementation, but open to other ideas -- to solve the "trusting on first use" problem.

Access to a Namecoin blockchain (either locally or via a trusted server) would allow the Gradle Witness plugin to check PGP signatures on JARs without trusting the files on a central repository.

I've drafted a topic paper, "Blockchain-based Trust for Software Components" for the Rebooting the Web of Trust conference and am thinking about using the Gradle Witness Plugin as a starting point for a proof-of-concept implementation.

Any feedback or assistance would be greatly appreciated. If there's interest the end result could be a pull-request to the Gradle Witness Plugin.

Witness currently resolves the dependency file with the following code:

ResolvedArtifact dependency = project.configurations.compile.resolvedConfiguration.resolvedArtifacts.find{
     return it.name.equals(name) && it.moduleVersion.id.group.equals(group)
}

Because this only checks the group and name, and not version, this resolves the most recent version of that dependency in the cache. If you have more than one version in your cache and you are not using the newest one, you may be getting false negatives, because the plugin is not checking the file you are using.

This can also cause false positives if you calculate & record your checksum before adding a newer version of the dependency to your cache because Witness will compare the hash of the most recent version to the hash you recorded from the older version.