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

Wed Dec 21 16:38:46 UTC 2016

Le 18/12/2016 à 02:08, Eli Schwartz a écrit :

> On 12/16/2016 05:08 PM, Bruno Pagani wrote:
>> Le 16/12/2016 à 20:52, Eli Schwartz a écrit :
>>> 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
> Um, actually, I've never thought about it from that perspective either,
> I think...
>
> The openssl fiasco wasn't really a case of the source code doing things
> that violate Debian standards (and hence is offensive *to Debian*
> specifically). It was *because* of their tampering that it did the wrong
> thing, but not necessarily an "offensive" thing.

Yes, but I see it more like “Debian tampering of upstream source” in
general, whether that’s offensive for them or not. ;) My point was:
Debian is not necessarily more trustworthy than upstream.

> I was actually thinking about xscreensaver.[1]

OK, that is far too long to read (only read a quarter of it, with “nice”
exchanges between users, Debian maintainers and upstream dev), would you
mind making me a summary (or pointing to a specific comment in the
thread doing so if there is one)?

>> 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?
> Correct. I agree that things should build against system libraries
> (except in cases like FS#43382 in which case the appropriate response is
> to work with upstream to make the software work properly with system
> libraries).
>
> Patching the build system is okay (but dirty) in that case, as long as
> upstream is notified in due course (so it can stop being dirty).
>
> However, I strongly believe that should only be done as patches applied
> to the unmodified and verifiable upstream source code. If the patches
> are from Debian, I am not suggesting we hate on Debian and reject it. ;)
> I am simply saying, use their patches and upstream's release tarball,
> rather than using Debian's modified tarball.

Thanks for this, will remember it. And FS#43382 was (or even is, since
it is apparently still living) quite interesting too. ;)

>>>>> 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.
> True, and signed sums generated by a "real upstream" is something I
> wouldn't mind having. But authenticating Debian's checksums is no better
> or worse than having an AUR maintainer ship a signature generated from
> the AUR maintainer's *own* GPG key!
>
> I disapprove of that in the AUR, so I won't hold us to a higher standard
> than I hold Debian. :)

Definitively agreed, that’s why this topic moved to verifying upstream
.dsc signed sums. ;)

>> 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?
> Correct. Towards the beginning of makepkg's runtime, it sources the
> PKGBUILD and at that time the grep magic occurs, because a PKGBUILD can
> contain any kind of bash hacks.
>
> However, ultimately the job of a PKGBUILD is to define certain variables
> and functions (at the time it is sourced), which makepkg will then use.
>
> Later on, makepkg does its "download all the sources" thing, looping
> through the source array and calling appropriate download agents to
> retrieve those sources.
> And later on yet, makepkg loops through the sources again and verifies
> them via the *sums array(s) and PGP signatures if available
>
> What you can do since you are after all relying on hacks ;) is to
> pre-download the dsc. You can always depend on curl to exist since
> pacman relies on it, and essentially it can be treated like a local source.

That looks fine for now. And it’s probably the most only thing we can do
in a reasonable time frame, since working around this in makepkg looks
definitively more hard than I thought. As a matter of fact, I’ve been
doing that in firefox-nightly-fr[1] for quite some time (this PKGBUILD
could need some simplification now that I’ve learned much more things,
will do this in my current PKGBUILD enhancement tour).

But in the case of upstream signed .dsc sums, this still require some
supplemental support on makepkg side. Do you think this could be
achievable easily? Even if to be honest, I’m not sure of any upstream
providing such signed sums, and that would be definitively OK then to
wait for actual cases to be reported before being implemented, so for
now an answer on whether this would be accepted if needed for this use
case would be sufficient. But that’s probably more for Allan to answer
this than you. ;)

>>> 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. ;)
> All this ^^ is really about "what is likely enough that we should build
> special handling into libmakepkg, rather than requiring each maintainer
> to reinvent the wheel/do more busywork".

Yes, and don’t you think that allowing easy verification of .dsc file
would be nice (i.e. without having to code it in a prepare{} function or
the like), even if the parsing and downloading of the sum file is still
to be handled by the maintainer in the PKGBUILD? Again, just wanting to
know whether that would be accepted in case of need, but since I, at
least, have none at the moment, there is no urge in implementing this
unless someone actually comes in with a lot of reported cases.

Thanks for all your enlightenment and contributions to this discussion,
Bruno

[1]:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=firefox-nightly-fr

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