[pacman-dev] [PATCH] makepkg: sums: Add FILE and SIGNED-MSG modes

[Olivier Brunel]

On 11/07/15 06:50, Allan McRae wrote:
> On 06/11/15 22:59, Olivier Brunel wrote:
>> On 11/06/15 06:12, Allan McRae wrote:
>>> On 06/11/15 04:48, Olivier Brunel wrote:
>>>> Verifying PGP signatures was only done by expecting them to be detached
>>>> signature of the source code, which is the case on many occasions.
>>>> However, some upstreams actually do things a bit differently, specifically there
>>>> are two other main ways things can be done:
>>>>
>>>> - a checksum file is provided, as well as a detached signature of that file. For
>>>>   such cases, this adds a special mode (alongside SKIP) to the sums array: FILE
>>>>   In that case, for filename.ext a file filename.ext.$ALGO is expected to be a
>>>>   standard checksum file - i.e. contain at least a line with the hash, spaces,
>>>>   then the filename - and the hash used will be the one from that file.
>>>>   Obviously this should be used when a detached signature of the file is
>>>>   provided, which will be treated by makepkg just as usual.
>>>>   An example package could be firefox.
>>>>
>>>> - a checksum file is provided as a signed message. For such cases, this adds a
>>>>   mode SIGNED-MSG, as it expects a file filename.ext.$ALGO.signed-msg to be the
>>>>   signed message. Upon hash checking, it will "extract" said message from the
>>>>   file via gpg, then use it much like in the FILE case.
>>>>   And during PGP signature checking, *.signed-msg files are verified as signed
>>>>   messages instead of detached signatures.
>>>>   An example package could be harfbuzz.
>>>>
>>>> Note that this doesn't change generation (--geninteg) since it can't be done
>>>> automatically.
>>>>
>>>> Signed-off-by: Olivier Brunel <jjk at jjacky.com>
>>>
>>> I am going to canvas on opinions for this.
>>>
>>> My opinion is that this should not be included in makepkg because of
>>> there being no standard on the format of any of these files.  You have
>>> used the output of coreutils hashing tools, but upstreams could use
>>> openssl, or anything else.  If we support one, we need to support them all.
>>
>> Well, I don't know... One could say the same about PGP signatures, if
>> one is supported, all must be. Clearly it isn't the case as of now :p
> 
> We support all detached signatures for source files.
> 
>> The format from coreutils tools is the only one I've seen used in
>> upstreams, not that it means anything, except at least that it is a
>> common one.
>>
>> As you said, there are no rules/standard for what upstream will do or
>> format they'll use, but this one is known (in fact I believe openssl has
>> an option to generate output in that format), and seems to be the
>> commonly used format; and supporting it allows to support more PGP
>> signature checking.
>>
>>
>>> Also, the packager needs to download the checksum files and their
>>> signatures to verify the source while packaging.  Putting the has in the
>>> PKGBUILD prevents everyone else doing this.  It also prevents upstream
>>> changing the released source (it happens...), and hash files and no-one
>>> noticing.
>>
>> Sorry, I don't understand what you mean by this:
>> Putting the hash in the PKGBUILD prevents everyone else doing this
>>
>> Could you explain/rephrase please? I don't get what gets prevented.
> 
> Which has goes in the PKGBUILD?  I assume you would have somethimg like:
> 
> source=("https://ftp.mozilla.org/pub/firefox/releases/42.0/source/firefox-42.0.source.tar.xz"
> 
> "firefox-42.0.source.tar.xz.sha256::https://ftp.mozilla.org/pub/firefox/releases/42.0/SHA512SUMS"
> 	"firefox-42.0.source.tar.xz.sha256.asc::https://ftp.mozilla.org/pub/firefox/releases/42.0/SHA512SUMS.asc")
> 
> sha256sums=("FILE" "SKIP" "SKIP")

(The filenames & array should read sha512, not sha256, but yes.)


> With that, upstream can change the file on the server and you will not
> notice.
> 
> If you don't use SKIP for the sha256 file, you need to update the
> PKGBUILD every time upstream ads a new release to the file.

Right; Okay so I think in your original mail, that last paragraph
("Also, ...") was meant to be informative, right? Just stating how
packaging should be done (i.e. not use ('FILE' 'SKIP' 'SKIP') but put
the hash of the checksum file in, for reasons stated), whereas I thought
you meant there was something that, with the use of those modes, wasn't
possible (anymore). I believe that was the source of my misunderstanding.

So, yes, the hash of the checksum file should go in, as explained, and
indeed you don't even need another sum array.

> 
>> As for upstream changing/"repackaging" a release, if that's something
>> you want to prevent, it can be done simply by adding another sums array.
>> E.g. one could use the sha256sums with SIGNED-MSG/FILE to check the hash
>> & signature from upstream, and the sha1sums (from the packager, i.e.
>> with actual hashes) to ensure things don't silently change from upstream
>> since original packaging.
>>
> 
> If you are putting other sums in the array, why not just put the sums
> from the signed file into the PKGBUILD after checking it?
>