[Rpm-maint] [rpm-software-management/rpm] RFE: read sources checksums from the SPEC file and verify them (#463)

Georg Sauthoff notifications at github.com
Sat Jul 14 10:24:39 UTC 2018


I'm perfectly fine with the rpm5 syntax and probably with most possible alternatives - as long as they are usable.

The rpm5 description I could find in the changelog mentions:

    digest([<algorithm>:]/path) = hex

I verify checksums all the time. The vast majority of open-source upstream also cares as you can see how much effort is put into publishing checksums for releases (e.g. published via independent channels, checksum files/release notes with checksums signed with a GPG key that is trusted by well-known project members etc.). I only have to deal with software with missing checksums when I have to get software from clueless corporations like Oracle (e.g. the download is only provided over http and often there is no checksum available at all, or just a md5 one or even just a CRC one).

I would argue that updating a checksum to the SPEC file is less tedious as the status-quo where you have to implement some outside checksum verification process/scripting. Also, with a new upstream release you already have to edit the spec file to adjust the version information.

Regarding 'SRPMs in rpm' - the SRPM isn't always the starting point. For example, for the quite popular Copr service it is not.

I can't see how adding checksums to a source downloads cache in a service like Copr would improve security. Because then the file is just downloaded (and checksummed) on the first request. And the source file could be very well comprised on that first download. Depending on the cache size and rebuild-frequency there are no more re-downloads such that such a compromise wouldn't be detected.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-405014175
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180714/a61dc4fe/attachment.html>


More information about the Rpm-maint mailing list