| Message ID | 20231206192527.90222-1-kilian.zinnecker@mail.de |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/1] configs/rock5b: add hash for custom kernel, uboot | expand |
Kilian, All, On 2023-12-06 20:25 +0100, kilian.zinnecker--- via buildroot spake thusly: > From: Kilian Zinnecker <kilian.zinnecker@mail.de> > > Signed-off-by: Kilian Zinnecker <kilian.zinnecker@mail.de> Thanks for the patch. BR2_DOWNLOAD_FORCE_CHECK_HASHES is quite new, so the rules for using it are still a bit in a flux. Peter provided some guidance in a later thread [0], and here's my extension on it: For wget downloads, be it http or https, we want a hash, because we want to protect against two problems: - man-in-the-midle attacks - rogue upstream replacing the release on the server For git-clone based downloads, with git:// of http or https, that retrieve a commit by sha1, we don't _need_ a hash file, because the sha1 of the commit is enough to know tht what we get is what we expect: if someone manahes to create a new commit with the same sha1 as an existing commit *and* with their attack payload, then we have a bigger issue (eveything will collapse, forges first). Then, for the rest of the download methods: I would believe Mercurial provides similar guarantees as git does, but I would not bet. For bzr, cvs, or svn, there is no question about them: they're not secure. scp or sftp are like wget over https: the transport is secure, protecting integrity, but we want to ensure the authenticity of the remote file. Now I realise one point that I completely forgot: if the upstream git tree disapears, we're left with downloading from a backup mirror (like s.b.o.). Or one can also use a primary mirror. In thoses cases, we do want to have a hash for the archive, even if the official is a git-clone repos. So, bottom line: we need a hash for all cases. Except when the remote is known to not be reproducible by design, which will be the few excpetions. I initially dropped the kernel part when applying your patch. But in light of what I wrote above, I'll push a follow up patch fixing it, sorry for the mess... [0] https://lore.kernel.org/buildroot/874jgpnn7d.fsf@48ers.dk/ Regards, Yann E. MORIN. > --- > board/radxa/rock5b/patches/linux/linux.hash | 2 ++ > board/radxa/rock5b/patches/uboot/uboot.hash | 2 ++ > configs/rock5b_defconfig | 1 + > 3 files changed, 5 insertions(+) > create mode 100644 board/radxa/rock5b/patches/linux/linux.hash > create mode 100644 board/radxa/rock5b/patches/uboot/uboot.hash > > diff --git a/board/radxa/rock5b/patches/linux/linux.hash b/board/radxa/rock5b/patches/linux/linux.hash > new file mode 100644 > index 0000000000..95ad749554 > --- /dev/null > +++ b/board/radxa/rock5b/patches/linux/linux.hash > @@ -0,0 +1,2 @@ > +# Locally calculated > +sha256 a5eca7b8f929a1918125e2e4fbd7ab4ea5b3910b5ae4547e81c794b47373ffb5 linux-52f51a2b5ba178f331af62260d2da86d7472c14b-br1.tar.gz > diff --git a/board/radxa/rock5b/patches/uboot/uboot.hash b/board/radxa/rock5b/patches/uboot/uboot.hash > new file mode 100644 > index 0000000000..efd629bd2f > --- /dev/null > +++ b/board/radxa/rock5b/patches/uboot/uboot.hash > @@ -0,0 +1,2 @@ > +# Locally calculated > +sha256 12e921b466ae731cdbc355e6832b7f22bc90b01aeceef9886f98aaba7b394300 u-boot-2023.07.tar.bz2 > diff --git a/configs/rock5b_defconfig b/configs/rock5b_defconfig > index eed656ef5f..2e72b386b1 100644 > --- a/configs/rock5b_defconfig > +++ b/configs/rock5b_defconfig > @@ -6,6 +6,7 @@ BR2_ROOTFS_POST_SCRIPT_ARGS="" > BR2_TARGET_GENERIC_HOSTNAME="rock5b" > BR2_TARGET_GENERIC_ISSUE="Welcome to the rock5b board" > BR2_GLOBAL_PATCH_DIR="board/radxa/rock5b/patches" > +BR2_DOWNLOAD_FORCE_CHECK_HASHES=y > BR2_SYSTEM_DHCP="eth0" > BR2_LINUX_KERNEL=y > BR2_LINUX_KERNEL_CUSTOM_GIT=y > -- > 2.25.1 > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: Hello, > Now I realise one point that I completely forgot: if the upstream git > tree disapears, we're left with downloading from a backup mirror (like > s.b.o.). Or one can also use a primary mirror. In thoses cases, we do > want to have a hash for the archive, even if the official is a git-clone > repos. > So, bottom line: we need a hash for all cases. Except when the remote is > known to not be reproducible by design, which will be the few > excpetions. I agree. > I initially dropped the kernel part when applying your patch. But in > light of what I wrote above, I'll push a follow up patch fixing it, > sorry for the mess... > [0] https://lore.kernel.org/buildroot/874jgpnn7d.fsf@48ers.dk/ Committed those two patches to 2023.11.x as well, thanks.
diff --git a/board/radxa/rock5b/patches/linux/linux.hash b/board/radxa/rock5b/patches/linux/linux.hash new file mode 100644 index 0000000000..95ad749554 --- /dev/null +++ b/board/radxa/rock5b/patches/linux/linux.hash @@ -0,0 +1,2 @@ +# Locally calculated +sha256 a5eca7b8f929a1918125e2e4fbd7ab4ea5b3910b5ae4547e81c794b47373ffb5 linux-52f51a2b5ba178f331af62260d2da86d7472c14b-br1.tar.gz diff --git a/board/radxa/rock5b/patches/uboot/uboot.hash b/board/radxa/rock5b/patches/uboot/uboot.hash new file mode 100644 index 0000000000..efd629bd2f --- /dev/null +++ b/board/radxa/rock5b/patches/uboot/uboot.hash @@ -0,0 +1,2 @@ +# Locally calculated +sha256 12e921b466ae731cdbc355e6832b7f22bc90b01aeceef9886f98aaba7b394300 u-boot-2023.07.tar.bz2 diff --git a/configs/rock5b_defconfig b/configs/rock5b_defconfig index eed656ef5f..2e72b386b1 100644 --- a/configs/rock5b_defconfig +++ b/configs/rock5b_defconfig @@ -6,6 +6,7 @@ BR2_ROOTFS_POST_SCRIPT_ARGS="" BR2_TARGET_GENERIC_HOSTNAME="rock5b" BR2_TARGET_GENERIC_ISSUE="Welcome to the rock5b board" BR2_GLOBAL_PATCH_DIR="board/radxa/rock5b/patches" +BR2_DOWNLOAD_FORCE_CHECK_HASHES=y BR2_SYSTEM_DHCP="eth0" BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y