Re: Changing checksums of RT patches

["Dominic Sacré" <dominic.sacre@gmx.de>]

Hi all,

I'm sorry to bring this up again, but it looks like
4.1/older/patch-4.1.38-rt45.patch.gz changed when -rt46 was released, so
the Bitbake recipes that use this patch are now broken again.

On 2017-02-28 19:03, Thomas Gleixner wrote:
> What matters is the content and not the compressed thingy. Again:
> 
>  - The sha256 only tells you that the download was not corrupted.
> 
>  - The PGP signature is what protects the content and that does not change
>    whether you move it or upload the same thing again.

I don't disagree, but there's currently no support for verifying
downloads by PGP signature in Bitbake; sha256 is the best we've got.

Besides, we're talking about a system for automated builds here.
I would argue that verifying the authenticity of files (e.g. using PGP
signatures) is the responsibility of the person writing the Bitbake recipe.
For those who then use that recipe to build the software, all that
matters is that the download is not corrupted, and that the file being
downloaded is actually the same one that was used by the author of the
recipe.

Of course, it really is the content that matters. But working with
sha256 checksums of the compressed files simplifies both the build
system, and, perhaps more importantly, the process of writing recipes.

IMHO it's bad practice for files to change once they've been released
(with a version number and everything), even if the contents remain the
same. The sha256-based approach seems to be working for thousands of
projects in OpenEmbedded; I don't see any particular reason for patches
on kernel.org to be any different.

By the way, the 4.1.38-rt46 release is currently still missing from the
"older" directory.


Cheers,

Dominic