On 10/31/2016 10:50 PM, Leonid Isaev wrote: > On Mon, Oct 31, 2016 at 06:04:48PM +0100, Levente Polyak wrote: >> I get your point what you try to achieve but the PKGBUILD already >> contains the integrity values (checksums) for all external sources and >> if you sign the PKGBUILD (which is the build script) then you have >> implicitly authenticated all integrity values of the external sources. >> >> A signature is nothing more (but also nothing less) then an >> authenticated checksum. If you sign a tarball then you "only" sign its hash. >> >> On top (like a bonus :P) if you sign the PKGBUILD then you did not only >> authenticate the checksums of the external sources but also the >> buildscript itself. So you really want so sign that instead ;) > > As a side question... is there a significant difference in signing PKGBUILD vs > the compiled package. Given that when building a pkg, I inspect the PKGBUILD, > what attack is possible when the PKGBUILD is not signed? Well that are two fundamentally different things. Signing the final binary package authenticates that the one you received and want to install is really what the dev/TU has built. Signing the build-script (PKGBUILD) adds exactly this authentication to the build-script that produced the given binary package. You obviously only have advantage out of it if you are using that build-script for anything (like building it yourself or for a rebuild by someone else). It's exactly why you want to have signatures from upstream (authors): to be sure who actually created it. Reading the build-script is good and especially in the AUR quite important... but at the end it mostly only saves you from obvious shit. If there is anyone evil who alters it to attack you then I'm convinced you most likely won't notice that by manually reading. It could be a small security related change in an existing patch-file that comes with the sources or as simple as a small swapped letter in the domain or github username that is added to the source array of the PKGBUILD and retrieves an evil version instead. > Also, isn't the use of dev signature to validate upstream sources is a logical > flaw? A dev might herself be mislead and build a trojaned source... > Sure, but I never said or claimed anything else. That's why i always insisted this to be a different topic (other then the original one). What i specifically said is that you need both as they have fundamental different areas they cover: On 10/31/2016 06:04 PM, Levente Polyak wrote: > Both cover certain areas but are still independent and one does not > make the other futile. By signing a PKGNBUILD of cause you don't "validate upstream sources" in a way you described. No matter what, but to validate authenticity of an upstream source, you obviously need an upstream signature. What you gain is that you add the same authentication to the build-script itself. Anyone obtaining a copy of it can verify it was really created by a dev/TU and everything it used or pulled in (with or without upstream signatures) is actually what that dev/TU had. Again: You want to have both to cover different areas that one or the other does not. cheers, Levente
Attachment:
signature.asc
Description: OpenPGP digital signature
