From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] [RFC] U-Boot: don't check hashes for U-Boot external patches
Date: Sun, 24 Apr 2016 18:11:23 +0200 [thread overview]
Message-ID: <20160424161123.GA2583@free.fr> (raw)
In-Reply-To: <5717E3FA.4010601@mind.be>
Arnout, Julien, All,
On 2016-04-20 22:18 +0200, Arnout Vandecappelle spake thusly:
> On 04/20/16 10:47, Julien Boibessot wrote:
> >On 19/04/2016 01:18, Arnout Vandecappelle wrote:
> >>On 04/18/16 12:28, Julien Boibessot wrote:
> >>>Hello,
> >>>
> >>>Arnout,
> >>>
> >>>thanks for the comments.
> >>>
> >>>On 14/04/2016 23:25, Arnout Vandecappelle wrote:
> >>[snip]
> >>>>
> >>>> Oh, and something similar should be done for LINUX_PATCH as well.
> >>>
> >>>LINUX_PATCH is already working well with external patches that have to
> >>>be downloaded.
> >>
> >> Of course, because we don't have a linux.hash and probably never will
> >>have one.
> >
> >ah ok, got it now ! :-)
> >So why can't we just get rid of uboot.hash too ?
>
> I don't think so.
Siding with Arnout on that one: we want to one day make .hash files
mandatory.
> For the kernel, it is very unlikely that you just use the latest version,
> most projects will want a specific version and usually even a patched
> version. With device trees this becomes somewhat less true, but even so,
> most people just don't use the latest-and-greatest kernel. Therefore, having
> hashes is quite useless.
Yes and no. We could well have hashes for the latest release, at least.
Then, when bumping, we can leave the old one and just add the new one;
thus hashes would be piling up as time goes, at least for official
releases.
Plus, we could also bulk-add hashes for older official releases. Official
releases are also very often used, at least for "standard" architectures
like x86, so it would not be nonsense to have hashes for those releases.
Normally, when a .hash file does exist, an archive must have at least
one hash, otherwise this is considered an error. NO_CHECK_HASH_FOR makes
it so that this is not an error that an archive does not have a hash,
but won't bar the existing hashes to be checked.
It's on my TODO to add hashes for the kernel.
Regards,
Yann E. MORIN.
> For u-boot (and barebox for that matter), this also used to be the case,
> but nowadays you can very often get away with just using the upstream
> version. In this case, the hash is indeed valuable.
>
> Cc-ing Yann, our hash expert :-)
>
> Regards,
> Arnout
>
>
> --
> Arnout Vandecappelle arnout at mind be
> Senior Embedded Software Architect +32-16-286500
> Essensium/Mind http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2016-04-24 16:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-14 14:32 [Buildroot] [PATCH] [RFC] U-Boot: don't check hashes for U-Boot external patches julien.boibessot at free.fr
2016-04-14 21:00 ` Arnout Vandecappelle
2016-04-14 21:25 ` Arnout Vandecappelle
2016-04-18 10:28 ` Julien Boibessot
2016-04-18 23:18 ` Arnout Vandecappelle
2016-04-20 8:47 ` Julien Boibessot
2016-04-20 20:18 ` Arnout Vandecappelle
2016-04-24 16:11 ` Yann E. MORIN [this message]
2016-06-12 21:36 ` Yann E. MORIN
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=20160424161123.GA2583@free.fr \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox