7 ms·

At Open Whisper Systems, we wrote a small open source gradle plugin called "gradle-witness" for this reason. Not just because dependencies could be transported

by moxie 12y ago

At Open Whisper Systems, we wrote a small open source gradle plugin called "gradle-witness" for this reason. Not just because dependencies could be transported over an insecure channel, but also because dependencies could be compromised if the gradle/maven repository were compromised: https://github.com/whispersystems/gradle-witness https://github.com/whispersystems/gradle-witness It allows you to "pin" dependencies by specifying the sha256sum of the jar you're expecting.

shortstuffsushi 12y ago
That's interesting, doesn't Maven offer a checksum option to begin with? I feel like just the other day, someone was saying "who ever uses checksums anyway," but a package manager run over insecure methods seems like the perfect time to do so.
- mike_hearn 12y ago
  For bitcoinj we developed a similar plugin for Maven: https://github.com/gary-rowe/BitcoinjEnforcerRules https://github.com/gary-rowe/BitcoinjEnforcerRules
- yourad_io 12y ago
  From the article: > When JARs are downloaded from Maven Central, they go over HTTP, so a man in the middle proxy can replace them at will. It’s possible to sign jars, but in my experimentation with standard tools, these signatures aren’t checked. The only other verification is a SHA1 sum, which is also sent over HTTP.
  - shortstuffsushi 12y ago
    I agree that they aren't checked by default, you'd need to implement it (as the parent commenter seemed to be doing with their gradle plugin). Regarding the sums being sent over HTTP as well, seems that you'll need a checksum for your checksum. Ultimately, though, it just seems that it'd be best to avoid this while it's over HTTP.
notthetup 12y ago
This! I am totally happy donating $10 to whisper systems for this work instead of forcing me to donate $10 to Apache Foundation (although a worthy cause) to be able to get https access to Maven Central.
- moxie 12y ago
  Thanks! You can support ongoing development by sending donations to our BitHub. Anyone who commits to an Open Whisper Systems repository will get 2% of your donation: https://whispersystems.org/blog/bithub/ https://whispersystems.org/blog/bithub/ The dashboard: http://bithub.whispersystems.org/ http://bithub.whispersystems.org/
heavenlyhash 12y ago
Hi moxie, might I ask if you've considered SHA-384 instead? If I understand correctly, SHA-256 is part of the SHA-2 family of hash algorithms, and like SHA-1, when used alone it is subject to length extension attacks. SHA-384 is also a member of the SHA-2 algorithm family, but is immune to length extension attacks because it runs with an internal state size of 512 bits -- by emitting fewer bits than its total internal state, length extensions are ruled out. (Wikipedia has a great table for clarifying all these confusing names and families of hashes: [5].) Other hashes like BLAKE-2 [1], though young, also promise built-in immunity to length-extension attacks. mdm [2] is immune to this because the relevant git datastructures all include either explicit field lengths as a prefix, or are sorted lists will null terminators, both of which diffuse length extension attacks by virtue of breaking their data format if extended. Not that it's by any means easy to find a SHA-256 collision at present; but should collisions be found in the future, a length extension attack will increase the leverage for using those collisions to produce binaries that slip past this verification. An md5 Collision Demo[3] by Peter Selinger is my favourite site for concretely demonstrating what this looks like (though I think this[4] publication by CITS mentions the relationship to length extension more explicitly). (I probably don't need to lecture to you of all people about length extensions :) but it's a subject I just recently refreshed myself on, and I wanted to try to leave a decent explanation here for unfamiliar readers.) -- I'm also curious how you handled management of checksums for transitive dependencies. I recall we talked about this subject in private back in April, and one of the concerns you had with mdm was the challenge of integrating it with existing concepts of "artifacts" from the maven/gradle/etc world -- though there is an automatic importer from maven now, mdm still requires explicitly specifying every dependency. Have you found ways to insulate gradle downloading updates to plugins or components of itself? What happens when a dependency adds new transitivity dependencies? I guess that's not a threat during normal rebuilds, since specifying hashes ahead of time already essentially forbids loosely semver-ish resolution of dependencies at every rebuild, but if it does happen during an upgrade, does gradle-witness hook into gradle deeply enough that it can generate warnings for new dependencies that aren't watched? This plugin looks like a great hybrid approach that keeps what you like from gradle and while starting to layer on "pinning" integrity checks. I'll recommend it to colleagues building their software with gradle. P.S. is the license on gradle-witness such that I can fork or use the code as inspiration for writing an mdm+gradle binding plugin? I'm not sure if it makes more sense to produce a gradle plugin, or to just add transitive resolution tools to mdm so it can do first-time setup like gradle-witness does on its own, but I'm looking at it! -- Edited: to also link the wikipedia chart of hash families. -- [1] https://blake2.net/ https://blake2.net/ [2] https://github.com/polydawn/mdm/ https://github.com/polydawn/mdm/ [3] http://www.mscs.dal.ca/~selinger/md5collision/ http://www.mscs.dal.ca/~selinger/md5collision/ [4] http://web.archive.org/web/20071226014140/http://www.cits.rub.de/MD5Collisions/ http://web.archive.org/web/20071226014140/http://www.cits.ru... [5] https://en.wikipedia.org/wiki/SHA-512#Comparison_of_SHA_functions https://en.wikipedia.org/wiki/SHA-512#Comparison_of_SHA_func...
jwn 12y ago
Cool, but am I right that it requires that you trust the jar dependency you have initially on your local filesystem?

by moxie 12y ago

shortstuffsushi 12y ago

That's interesting, doesn't Maven offer a checksum option to begin with? I feel like just the other day, someone was saying "who ever uses checksums anyway," but a package manager run over insecure methods seems like the perfect time to do so.

mike_hearn 12y ago
For bitcoinj we developed a similar plugin for Maven: https://github.com/gary-rowe/BitcoinjEnforcerRules https://github.com/gary-rowe/BitcoinjEnforcerRules
yourad_io 12y ago
From the article: > When JARs are downloaded from Maven Central, they go over HTTP, so a man in the middle proxy can replace them at will. It’s possible to sign jars, but in my experimentation with standard tools, these signatures aren’t checked. The only other verification is a SHA1 sum, which is also sent over HTTP.
- shortstuffsushi 12y ago
  I agree that they aren't checked by default, you'd need to implement it (as the parent commenter seemed to be doing with their gradle plugin). Regarding the sums being sent over HTTP as well, seems that you'll need a checksum for your checksum. Ultimately, though, it just seems that it'd be best to avoid this while it's over HTTP.

notthetup 12y ago

This! I am totally happy donating $10 to whisper systems for this work instead of forcing me to donate $10 to Apache Foundation (although a worthy cause) to be able to get https access to Maven Central.

moxie 12y ago
Thanks! You can support ongoing development by sending donations to our BitHub. Anyone who commits to an Open Whisper Systems repository will get 2% of your donation: https://whispersystems.org/blog/bithub/ https://whispersystems.org/blog/bithub/ The dashboard: http://bithub.whispersystems.org/ http://bithub.whispersystems.org/

heavenlyhash 12y ago

Hi moxie, might I ask if you've considered SHA-384 instead? If I understand correctly, SHA-256 is part of the SHA-2 family of hash algorithms, and like SHA-1, when used alone it is subject to length extension attacks. SHA-384 is also a member of the SHA-2 algorithm family, but is immune to length extension attacks because it runs with an internal state size of 512 bits -- by emitting fewer bits than its total internal state, length extensions are ruled out. (Wikipedia has a great table for clarifying all these confusing names and families of hashes: [5].) Other hashes like BLAKE-2 [1], though young, also promise built-in immunity to length-extension attacks. mdm [2] is immune to this because the relevant git datastructures all include either explicit field lengths as a prefix, or are sorted lists will null terminators, both of which diffuse length extension attacks by virtue of breaking their data format if extended. Not that it's by any means easy to find a SHA-256 collision at present; but should collisions be found in the future, a length extension attack will increase the leverage for using those collisions to produce binaries that slip past this verification. An md5 Collision Demo[3] by Peter Selinger is my favourite site for concretely demonstrating what this looks like (though I think this[4] publication by CITS mentions the relationship to length extension more explicitly). (I probably don't need to lecture to you of all people about length extensions :) but it's a subject I just recently refreshed myself on, and I wanted to try to leave a decent explanation here for unfamiliar readers.) -- I'm also curious how you handled management of checksums for transitive dependencies. I recall we talked about this subject in private back in April, and one of the concerns you had with mdm was the challenge of integrating it with existing concepts of "artifacts" from the maven/gradle/etc world -- though there is an automatic importer from maven now, mdm still requires explicitly specifying every dependency. Have you found ways to insulate gradle downloading updates to plugins or components of itself? What happens when a dependency adds new transitivity dependencies? I guess that's not a threat during normal rebuilds, since specifying hashes ahead of time already essentially forbids loosely semver-ish resolution of dependencies at every rebuild, but if it does happen during an upgrade, does gradle-witness hook into gradle deeply enough that it can generate warnings for new dependencies that aren't watched? This plugin looks like a great hybrid approach that keeps what you like from gradle and while starting to layer on "pinning" integrity checks. I'll recommend it to colleagues building their software with gradle. P.S. is the license on gradle-witness such that I can fork or use the code as inspiration for writing an mdm+gradle binding plugin? I'm not sure if it makes more sense to produce a gradle plugin, or to just add transitive resolution tools to mdm so it can do first-time setup like gradle-witness does on its own, but I'm looking at it! -- Edited: to also link the wikipedia chart of hash families. -- [1] https://blake2.net/ https://blake2.net/ [2] https://github.com/polydawn/mdm/ https://github.com/polydawn/mdm/ [3] http://www.mscs.dal.ca/~selinger/md5collision/ http://www.mscs.dal.ca/~selinger/md5collision/ [4] http://web.archive.org/web/20071226014140/http://www.cits.rub.de/MD5Collisions/ http://web.archive.org/web/20071226014140/http://www.cits.ru... [5] https://en.wikipedia.org/wiki/SHA-512#Comparison_of_SHA_functions https://en.wikipedia.org/wiki/SHA-512#Comparison_of_SHA_func...

jwn 12y ago

Cool, but am I right that it requires that you trust the jar dependency you have initially on your local filesystem?