On Sat, 15 Aug 2020 21:24:08 -0400 Mark H Weaver wrote: > Hi Alexandre, > > I thought about it some more, and I've changed my mind on one point: > I've decided that for future kernel updates, in order to eliminate the > risk of unintentionally allowing blobs into Guix, I will either wait > for Linux-libre to publish updated deblob scripts, or else I will > manually check for new blobs. This can be determined by checking for the availability of the new kernel version in git. The git repository is updated first, prior to tarballs being created so I assume you'd want to be looking there given that speed of updates seems important. If the new kernel version appears without a corresponding script update then you can know that no script updates were determined to be necessary. Wouldn't a better setup be to obtain the desired kernel version from Linux-libre, obtain the desired kernel version from kernel.org, independently run the clean-up scripts, and then toss out the results from kernel.org once the source code is determined to be identical?* I mean, if you're already willing to wait until the analysis of whether updated cleanup scripts are needed or not has been done, then you're already at the point of the Linux-libre kernel source code being available too because once that determination is made, any updated scripts and the corresponding kernel source code are pushed into git simultaneously. Confirming if the results you get from the cleanup scripts are the same is helpful all around. It is not necessary to trust the Linux-libre project infrastructure because you're also verifying the integrity and also gets you access to the double verification steps that are done which check that the version does in fact correspond to the upstream version plus the changes that Linux-libre made, and that it also corresponds to the previous release plus the incremental patches. * As a disclaimer there may be one difference in that the clean-up scripts will in some cases delete all of the files in a directory while leaving the directory itself in place. Git doesn't track empty directories and so diffing of the entire kernel source code would reveal that. The diff should otherwise report everything to be identical.