All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: kilian.zinnecker@mail.de
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/1] configs/rock5b: add hash for custom kernel, uboot
Date: Sat, 23 Dec 2023 19:44:06 +0100	[thread overview]
Message-ID: <ZYcqdkBK1XbKOmlq@landeda> (raw)
In-Reply-To: <20231206192527.90222-1-kilian.zinnecker@mail.de>

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 E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2023-12-23 18:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-06 19:25 [Buildroot] [PATCH 1/1] configs/rock5b: add hash for custom kernel, uboot kilian.zinnecker--- via buildroot
2023-12-23 18:44 ` Yann E. MORIN [this message]
2024-01-08 11:06   ` Peter Korsgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZYcqdkBK1XbKOmlq@landeda \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@buildroot.org \
    --cc=kilian.zinnecker@mail.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.