[arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Levente Polyak]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20161101/a58602f6/attachment-0001.asc>