[PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

[Brian Inglis]

On 2024-05-06 09:52, Jon Turney via Cygwin-apps wrote:
> On 01/05/2024 17:48, Brian Inglis via Cygwin-apps wrote:
>> On 2024-04-30 23:32, ASSI via Cygwin-apps wrote:
>>> Brian Inglis via Cygwin-apps writes:
>>>> Some package upstreams offer only checksums, for example .sha512sum, 
>>>> .sha256sum, for verification rather than gpg signatures, for example
>>>> .asc, .sig, .sign, etc;
>>>> use these checksum files when provided in a similar manner to gpg signatures;
>>>> these files are often provided with fixed names which may be renamed
>>>> on download to unique values using cygport URI fragment support like 
>>>> #/$NAME-VERSION.sha...sum;
>>>> use coreutils cksum as it supports all modern and legacy checksums and formats.
>>
>>> https://repo.or.cz/cygport/rpm-style.git/commitdiff/c956092ce8d90230b812fb05ad2b4da13df1e36d
>>
>> Two similar independent implementations mean it would be a good idea to add 
>> the feature!
>>
>> Mine preferred cksum as being the most general approach, while not worrying or 
>> knowing too much about ancient sums, although your implementation is better, 
>> that is, works properly on those.
>>
>> Mine also preferred sha*sum file types, while still allowing prefixes only 
>> without sum, not enumerating them all in the unpack() case, and respecting the 
>> cksum crc default.
> 
> I guess this makes sense as a part of the fetch operation, in those cases where 
> upstream provides signatures or checksums.

I will retry incorporating Achim's approach so hopefully we can both retire our 
local cygport patches.

I would also appreciate other comments or feedback to my reply to Achim's NAK on 
my patch for `gpgv` replacing `gnupg2 --verify`?

> But as briefly discussed in [1], independently of that it would also be a good 
> idea for cygport to specify it's own checksum file, which is incorporated into 
> the source package, and verified at build prep time.

As in Fedora RPM package `sources` BSD-style sum prefix, for example (one line):

https://src.fedoraproject.org/rpms/bash-completion/blob/rawhide/f/sources
SHA512 (bash-completion-2.13.0.tar.xz) = 
7c65fea599a25c2c9d6ef300a9cc2d5fbabd0bcc9e09fe32bb706d3398936f40501171f03280f042465bc0d9aca4b1b53c2c13a99bbdfb6fe916767a267158af

or also in the source package for cygport and each source file included, as in 
Debian dsc, for example:

https://deb.debian.org/debian/pool/main/b/bash-completion/bash-completion_2.13.0-1.dsc
Checksums-Sha1:
  0c045cc06b57bbe8945bc6c4ea8f2b52f1285903 484155 bash-completion_2.13.0.orig.tar.gz
  66f10d161e71c0725a61d5bde1c6b89f9bdb61e3 17840 
bash-completion_2.13.0-1.debian.tar.xz
Checksums-Sha256:
  6c1cc04bb506e7ba6bd7bb3c7c6f6ad2b46e6198e86666ef4c88139597250601 484155 
bash-completion_2.13.0.orig.tar.gz
  d2de6c33d14843da64e4b20e6330c14079b2c73f04c9b4c544d6435930003a67 17840 
bash-completion_2.13.0-1.debian.tar.xz
Files:
  93527b12850a781744e3f335f904bdf1 484155 bash-completion_2.13.0.orig.tar.gz
  a831ae35940daf95016fce1b655955a1 17840 bash-completion_2.13.0-1.debian.tar.xz

> (Since this would protect against such screw ups, help with build 
> reproducibility, and defend against supply chain attacks on upstream)
> 
> [1] https://cygwin.com/pipermail/cygwin-apps/2024-March/043540.html

Coreutils `cksum` does BSD-style checksums, although I would prefer sha256 sums 
for brevity and consistency with setup.ini, and base64 encoding rather than hex 
to shorten the checksum representation, in recent coreutils.

We all have SSH keys, which I also have as a GPG key, could we also use them for 
signing source packages?
Calm could validate ours and checksums, and re-sign with Cygwin key, which setup 
could validate.
Could osslsigncode have any application here?

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry