[pacman-dev] Could makepkg verify .dsc file?

[Bruno Pagani]

Le 16/12/2016 à 05:57, Eli Schwartz a écrit :

> On 12/15/2016 06:23 PM, Bruno Pagani wrote:
>> Le 16/12/2016 à 00:13, Allan McRae a écrit :
>>
>>> On 16/12/16 08:29, Bruno Pagani wrote:
>>>> Hi there,
>>>>
>>>> This is probably some sort of feature request or maybe more general asking.
>>>>
>>>> I have a case where sha*sums are provided in a .dsc signed file
>>>> (bs1770gain, for which *sane* upstream is Debian:
>>>> https://packages.debian.org/source/sid/bs1770gain). Apparently, makepkg
>>>> only supports verifying file with detached signature. Is there a
>>>> specific reason for that (like this use case is really tiny — I have no
>>>> actual idea about this) or is it just because it was never implemented?
>>>>
>>> The format of signed checksum files varies a lot.  I don't want to
>>> attempt to autodetect each one as that will create a future nightmare.
>>>
>>> Also, what is gained vs putting the checksums into the PKGBUILD?
>>>
>>> A
>> Easy verification of source for other people building the package (here
>> from AUR, but could be from ABS). Or maybe I misunderstood the point of
>> having PGP verification in makepkg?
> PGP verification proves that upstream signed the sources. Debian .dsc
> files prove nothing other than that Debian signed that download.

You’re right about this, but in this particular case Debian does import
and check the code in their own tree on each release, so their signature
has a meaning to me. And also, they used to modify it (the source code),
but thanks to your below question I have checked that again and it’s no
longer the case. So in some way it’s like Debian signed some sort of
code audit, or regarding the second point like they’ve forked the
project and signed they own releases.

> What exactly qualifies Debian as the "sane upstream" anyway?

Well, at some point bs1770gain build system was downloading needed libs
from around the internet at build time rather than linking against
system ones, but that has been fixed upstream. I’m probably going to
switch to upstream unsigned tarball, since the second point (“forked
project”) doesn’t apply anymore, though the first one is still valid
IMHO. If you have any opinion on this, please share it. ;)

> What does authenticating Debian's checksums get us, that we couldn't
> have gotten out of verifying the AUR maintainer's checksums?

Not sure to understand that one: what’s the point of PGP at all in
makepkg then? Like I’ve said in my other emails responding to Allan, how
is this different from a signed source verified by the maintainer while
having just the checksum pasted in the PKGBUILD?

Or if it’s just because of Debian vs real upstream again, see my point
above and below.

> Note that Allan has already vetoed the idea of upgrading the default
> checksum type in makepkg, on the grounds that it doesn't really prove
> anything, and nothing other than actual checksums or preferably PGP
> signatures from the code author will prove *anything*.

And I totally agree with that. The ambiguity here is around “code
author”, since in that case I consider Debian to fulfil this role, but I
definitively would like to hear your opinion on this now that I (hope
to) have enlightened some points.

> So I don't see why yet more unproven checksums will be any different,
> especially if it requires brand-new handling in makepkg specifically for
> the purpose.

Agree again, but my point is not about this package in particular, it’s
in the event of upstream providing sha*sums in a signed file as opposed
to a detached signature. Not that currently makepkg supports verifying a
sha*sums with detached signatures (maybe not by design but as
consequence of source signature verification).

Bruno

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 525 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20161216/00175305/attachment.asc>