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

Fri Dec 16 22:08:01 UTC 2016

Le 16/12/2016 à 20:52, Eli Schwartz a écrit :

> On 12/16/2016 08:37 AM, Bruno Pagani wrote:
>> 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.
> Not really true in the general case. :p There are several somewhat
> famous Debian bugs regarding software they shipped that did what was to
> them very offensive things, and the maintainer got thoroughly scolded
> for having failed to catch it.

Indeed, never thought of “Debian OpenSSL keys” from that perspective. :p

> Point being, we are all human. Supposedly, Arch/AUR maintainers check
> the code they use too. Debian are not some magical group of exalted
> beings with higher standards of correctness that can be depended on. I
> imagine careless AUR maintainers are no more common than careless Debian
> maintainers -- or vice versa! ;)

That’s right in general indeed, and starting to do case by case is
probably not a good idea. ;)

>> 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. ;)
> Well then, they are doing a better job packaging this than they did in
> the openssl fiasco. ;)

Definitively. :)

> Joking aside, that still doesn't make them an upstream, ever. I would
> still recommend using official upstream-sanctioned sources

I’ll switch bs1770gain to that then. But I have the impression you’re
seing that even before I should have used upstream source despite their
ugly/shadowy build system, is that the case? Maybe while carrying Debian
patch to build correctly aside?

>>> 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?
> PGP in makepkg does whatever you tell it to, which unlike checksums is
> *capable* of supplying authority in addition to integrity.

Yes, but signed sums are just one more step away from this setup.

>> Or if it’s just because of Debian vs real upstream again, see my point
>> above and below.
> But yes, it is "Debian vs. real upstream",  and I am not yet convinced.

And you’re right not to be, since you stand with the valid opinion here. ;)

>> 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.
> They are only an author for their modifications, and as for the rest
> they are a code *auditor*. But so are Arch/AUR maintainers.
>
> And see how that works out, in both projects, at scale. :(

OK, fair point, I think it answers my above questions by yes and yes. :)

>> 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).
> Well, Firefox upstream for one supplies sha512sums in a signed file.[1]
> So this could in theory be used.
>
> The problem is that you can copy the checksums into the PKGBUILD and
> PGP-verify the checksum file, but unless you seriously reorganize
> makepkg's verification logic you cannot download the checksum file,
> PGP-verify it and *then* check the other files based on the checksum
> file. And I don't think anyone else strongly cares about doing that, but
> maybe if you provided a patch it would be accepted?

Interesting, ever thought it worked, but apparently it was because the
file was already downloaded in my workdir (since I needed the sha*sum of
the sha*sums file — see why in Olivier Brunel answer).

I had this in my bs1770gain PKGBUILD:

source=("http://http.debian.net/debian/pool/main/b/${pkgname}/${pkgname}_${pkgver}"{.orig.tar.gz,-1.dsc})
sha256sums=("$(grep -A1 Sha256 ${pkgname}_${pkgver}-1.dsc | tail -n 1 |
cut -d ' ' -f 2)"
'4011c60f797c55ddf1eb0ce6ad981bc48a70a96bc7d7b3152ddb740cc2b46bbb')

And it worked like a charm, but after deleting the .dsc file it indeed
failed. Just relaunching makepkg was enough to make it success, but
that’s not a sane workflow.

I’m not familiar with makepkg code, but would it really be that hard to
allow such things to work? I’m not sure why makepkg can’t see the
downloaded file the first time but can the second, is that because the
commands in sha256sums are executed before downloading?

> The other problem is formats for checksum files. ;) Theoretically, the
> reusable output of sha*sum is a standard, but in practice some use the
> BSD-style type, and as witnessed in the Firefox checksum manifest, there
> may be many files listed in one checksum file using complex paths, so
> that would have to be filtered.

Or just allow the above setup and let the parsing of the checksum file
at maintainer responsibility?

> As for attached signatures, that is hardly a Debian-specific idea, but I
> confess I don't usually see file resources with attached signatures
> floating around. The thing about them is that you need to have gpg in
> order to transform the file into something usable -- that's why the
> detached signature exists.

Yes indeed, file resources with attached signature are not likely to
exist. But this is really about signed checksums.

> So I think it is, in practice, more or less limited to inline signing of
> *messages*, and makepkg doesn't usually need to worry about those. But
> in theory we could fix that and teach makepkg how to recognize sources
> with builtin signatures. (Actually the case with git, and I had to
> special-case it to add signed commit/tag support.)

Yes indeed, it’s all about inline signing of messages, those messages
being sha*sums of the resource file. ;)

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/e110914d/attachment.asc>