s/possible/possibly/ s/checksum in there/checksum in the PKGBUILD as usual/ On Mon, Oct 21, 2013 at 10:19 PM, Ido Rosen wrote:

- Do PKGBUILDs support signing the PKGBUILD and verifying that signature? (This seems like a good feature for yaourt or possible makepkg if it isn't one already.) It seems like if you want safety from MITM attacks, PGP sigs are the way to go, either sign the PKGBUILD and put the checksum in there, or include the signature of the source file in the tarball/pkg. (This is already provided for binary pkgs, but not source ones, correct? Seems easy enough to add a PKGBUILD signature and teach makepkg to use it.)

On Mon, Oct 21, 2013 at 10:13 PM, Doug Newgard wrote:

...

----------------------------------------

...

From: adys.wh@gmail.com Date: Tue, 22 Oct 2013 01:56:16 +0100 To: aur-general@archlinux.org Subject: [aur-general] Support for remote sums in PKGBUILDs

Breaking away from an IRC convo from this morning; has support for remote sums been considered for pacman? It's currently possible to do this for .sig files (through the source array), but not available for simple sha/md5 hashes. This would let packagers do something like: source=("http://example.com/downloads/$pkgname-$pkgver.tar.xz") sha1sums=("http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1")

(Of course, only for servers that generate a programmatically discoverable hash of some sort; but it's not actually uncommon)

J. Leclanche

Couldn't you just do: sha1sums=("$(curl http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1)")

It kind of defeats the purpose, though. If the server is hacked or someone does a MitM, they can easily replace the checksum file as well.

It'd be nice to have as an option - especially since the key fingerprint is easy to look up on the AUR website. Then tools like yaourt or makepkg can alert you when the keyID of the sig, for example, differs from the one that signed the currently installed version during an upgrade, as a means of allowing for integrity continuity. (There are other things that could be done with this feature, but this is a useful one from a MITM standpoint, so at least you know the new PKGBUILD is from the same author as the old PKGBUILD your pkg was generated from, for example.) On Mon, Oct 21, 2013 at 10:40 PM, Doug Newgard wrote:

----------------------------------------

...

Date: Mon, 21 Oct 2013 22:19:32 -0400 From: ido@kernel.org To: aur-general@archlinux.org Subject: Re: [aur-general] Support for remote sums in PKGBUILDs

- Do PKGBUILDs support signing the PKGBUILD and verifying that signature? (This seems like a good feature for yaourt or possible makepkg if it isn't one already.) It seems like if you want safety from MITM attacks, PGP sigs are the way to go, either sign the PKGBUILD and put the checksum in there, or include the signature of the source file in the tarball/pkg. (This is already provided for binary pkgs, but not source ones, correct? Seems easy enough to add a PKGBUILD signature and teach makepkg to use it.)

On Mon, Oct 21, 2013 at 10:13 PM, Doug Newgard

...

----------------------------------------

...

From: adys.wh@gmail.com Date: Tue, 22 Oct 2013 01:56:16 +0100 To: aur-general@archlinux.org Subject: [aur-general] Support for remote sums in PKGBUILDs

Breaking away from an IRC convo from this morning; has support for remote sums been considered for pacman? It's currently possible to do this for .sig files (through the source array), but not available for simple sha/md5 hashes. This would let packagers do something like: source=("http://example.com/downloads/$pkgname-$pkgver.tar.xz") sha1sums=("http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1")

(Of course, only for servers that generate a programmatically discoverable hash of some sort; but it's not actually uncommon)

J. Leclanche

Couldn't you just do: sha1sums=("$(curl http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1)")

It kind of defeats the purpose, though. If the server is hacked or someone does a MitM, they can easily replace the checksum file as well.

Let's be realistic here, you're not going to get all of the PKGBUILDs in the AUR signed with PGP.

This idea is a little bit more impractical, but: Handoff could be done cryptographically as well - a signed PKGBUILD could carry a source file that has a transfer-of-maintainership signature (e.g. a clearsigned message with the date and name of the package/base) by the old key signing the new key's key fingerprint + packagename + date, to allow people to transfer maintainership to a new key without raising the alarm, if desired. On Mon, Oct 21, 2013 at 10:53 PM, Ido Rosen wrote:

(Just an additional implementation detail, but this would mean the verified keyID/fingerprint on the PKGBUILD that generated the pkg gets included in the pkg somehow, not that the pkg needs to be signed by the same key as the PKGBUILD was.)

On Mon, Oct 21, 2013 at 10:44 PM, Ido Rosen wrote:

...

It'd be nice to have as an option - especially since the key fingerprint is easy to look up on the AUR website. Then tools like yaourt or makepkg can alert you when the keyID of the sig, for example, differs from the one that signed the currently installed version during an upgrade, as a means of allowing for integrity continuity. (There are other things that could be done with this feature, but this is a useful one from a MITM standpoint, so at least you know the new PKGBUILD is from the same author as the old PKGBUILD your pkg was generated from, for example.)

On Mon, Oct 21, 2013 at 10:40 PM, Doug Newgard wrote:

...

----------------------------------------

...

Date: Mon, 21 Oct 2013 22:19:32 -0400 From: ido@kernel.org To: aur-general@archlinux.org Subject: Re: [aur-general] Support for remote sums in PKGBUILDs

- Do PKGBUILDs support signing the PKGBUILD and verifying that signature? (This seems like a good feature for yaourt or possible makepkg if it isn't one already.) It seems like if you want safety from MITM attacks, PGP sigs are the way to go, either sign the PKGBUILD and put the checksum in there, or include the signature of the source file in the tarball/pkg. (This is already provided for binary pkgs, but not source ones, correct? Seems easy enough to add a PKGBUILD signature and teach makepkg to use it.)

On Mon, Oct 21, 2013 at 10:13 PM, Doug Newgard

...

----------------------------------------

...

From: adys.wh@gmail.com Date: Tue, 22 Oct 2013 01:56:16 +0100 To: aur-general@archlinux.org Subject: [aur-general] Support for remote sums in PKGBUILDs

Breaking away from an IRC convo from this morning; has support for remote sums been considered for pacman? It's currently possible to do this for .sig files (through the source array), but not available for simple sha/md5 hashes. This would let packagers do something like: source=("http://example.com/downloads/$pkgname-$pkgver.tar.xz") sha1sums=("http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1 ")

(Of course, only for servers that generate a programmatically discoverable hash of some sort; but it's not actually uncommon)

J. Leclanche

Couldn't you just do: sha1sums=("$(curl http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1)")

It kind of defeats the purpose, though. If the server is hacked or someone does a MitM, they can easily replace the checksum file as well.

Let's be realistic here, you're not going to get all of the PKGBUILDs in the AUR signed with PGP.

Den 22-10-2013 04:13, Doug Newgard skrev:

It kind of defeats the purpose, though. If the server is hacked or someone does a MitM, they can easily replace the checksum file as well.

I never really thought much of the security of checksumming, basically exactly because they're relatively "easy" to forge (if you have access to where the files are, if you have access to the raw network stream, if you have access to the client machine). This goes for PKGBUILDs as well, for that matter. I agree that there is some measure of security inherent in checksumming, just not that it's significant. :) I mostly regard checksums as a way to ensure that a download was not corrupted "in transit". This could be achieved by "remote checksums" as well as local ones you have to update all the time. -- Frederik "Freso" S. Olesen http://freso.dk/