On 10/31/2016 06:04 PM, Levente Polyak wrote:

On the other side we have a dev/TU authenticating the buildscript. Both cover certain areas but are still independent and one does not make the other futile.

Since this thread is helpfully on arch-general now, I want to quickly chime in and say that I would really like authenticated buildscripts at some point :) Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808

Any PKGBUILD kept in git can already optionally have this feature. See git-commit(1), specifically, its --gpg-sign option.

I know that, I have [commit] gpgsign = true in my ~/.gitconfig. It would be nice if more people did that and if makepkg checked that, though. It would probably be counter-productive to enforce it on the AUR through a git hook, but maybe a warning or something? I might post that to aur-general at some point. Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808

On 11/01/2016 12:40 AM, Allan McRae wrote:

I would like some bourbon.

Allan

I like your sense of humor :)

* It might appear unrelated, but I can spend time on pacman/makepkg if I don't have to work for bourbon. Then again, bourbon reduces the quality of my coding after a point...

I wasn't asking you to do more work, you do enough good work already. I might work on that myself, my studies take up too much time right now though. Remotely related: https://www.xkcd.com/323/ Btw, maybe I might by you some bourbon one day, I'm in Europe though. What kind do you like? Or would you want actual scotch instead?

** makepkg --source --sign

I know about that, it won't help the AUR though :) -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808

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

On Mon, Oct 31, 2016 at 07:18:01PM -0400, Eli Schwartz via arch-general wrote:

On 10/31/2016 05:50 PM, Leonid Isaev wrote:

...

As a side question... is there a significant difference in signing PKGBUILD vs the compiled package.

Do you realize, when you ask if there is a difference between signing a PKGBUILD vs. a built package, it sounds an awful lot like asking if there is a difference between a PKGBUILD and a built package?

It does not, really...

...

Given that when building a pkg, I inspect the PKGBUILD, what attack is possible when the PKGBUILD is not signed?

Off the top of my head, there is *the topic of this thread*. Someone could modify the checksums and deliver fake sources. When the PKGBUILD just says "run `make`", how do you tell the difference?

Well, my mentality is that authenticating plain-text data is usually not necessary because a user can always inspect it (notice, I don't care if a PKGBUILD comes from an authentic source, I only care if its not doing smth malicious). This is why I inspect the PKGBUILD and corresponding install files / patches. At least, I thought this is why PKGBUILDs are not signed in the same manner that Gentoo signs ebuilds... Regarding checksums, how did a dev know that upstream sources are authentic? I use a similar judgement (as a practical example, in my packages I always maintain multiple checksums: one from Arch, another from Gentoo, third from Debian/Fedora, and have a keyring with all upstream keys I can get). But anyway, my question has already been answered... Thanks, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On 01 Nov 2016, at 00:35, Leonid Isaev wrote:

Well, my mentality is that authenticating plain-text data is usually not necessary because a user can always inspect it

You just can't reliably inspect plain text install data, unless you spend an awful lot of time on it. As already pointed out, it's just too easy to miss out small malicious changes. And even if you were able to spot those, most average users won't, and that's what policies are meant for: the average user.

Regarding checksums, how did a dev know that upstream sources are authentic?

It's not about the upstream source to be authentic, it's about the upstream source reached your hard drive without further (malicious) modification. That saying, you can't expect a package maintainer to review all the code he uses (indirectly) in his package. If you use another (open source) project, that one could always be malicious. But we'll assume that case not likely (in general). It is much more likely that an attacker will try to break things you install (although I still assume that this is not often), than a group of attackers hiding malicious software in an (open source) project. The former can be easily locked out by checksums, the latter only by extensive code reviews. And even if they were done, you'd still have to trust the one who did the review. Since there's an easy fix for the former, let's use it. Since there is none for the latter, let's keep an eye on this. There's always trust to a certain degree. Cheers, Lukas