Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Gaël PORTAY" <gael.portay@savoirfairelinux.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] support/download: print dl hash if not provided
Date: Mon, 23 Oct 2017 08:47:18 -0400	[thread overview]
Message-ID: <20171023124718.zsdv7exoc3j2guim@archlinux> (raw)
In-Reply-To: <c473939d-e763-165f-5451-cd940f56fa38@mind.be>

Hi Arnout,

On Mon, Oct 23, 2017 at 11:10:32AM +0200, Arnout Vandecappelle wrote:
>  Hi Ga?l,
> 
> On 11-09-17 21:12, Ga?l PORTAY wrote:
> > Yann,
> > 
> > On Sun, Sep 10, 2017 at 11:29:55AM +0200, Yann E. MORIN wrote:
> >> Ga?l, All,
> >>
> >> On 2017-07-19 23:18 -0400, Ga?l PORTAY spake thusly:
> >>> ...
> >>>
> >>> It also fixes check_one_hash description. check_one_hash() takes three
> >>> arguments:
> >>>  - algo hash
> >>>  - known hash
> >>>  - file to hash
> >>>
> >>> Signed-off-by: Ga?l PORTAY <gael.portay@savoirfairelinux.com>
> >>
> >> NAK from me.
> >>
> >> The reason we do not want this is that we instead want the user to go
> >> fetch the hash(es) as provided by upstream, like in an announcement
> >> email, or in an on-the-side hash file.
> >>
> >> Having the download infra print the locally computed hash defeats the
> >> very purpose of hashes: check that we get what upstream provides.
> >>
> >> We only accept local calculations of hashes for the cases where upstream
> >> does not provide any (or too weak) hash.
> >>
> > 
> > Okay.
> 
>  Thomas and I discussed this at the BR developer meeting, and we disagree with
> Yann that we should make life difficult for people bumping a package :-P. So we
> think this patch does have value. Would you be willing to respin it?
> 

For sure. Let me do a rebase and I will respin it at the end of the day.

>  However, the text you propose is not strong enough. How about:
> 
>        Please find a hash in the upstream announcement or website
>        and add it to ${h_file}
>        If upstream doesn't provide a hash and the source is trusted,
>        consider adding these lines:
> 

I agree.

>  Also, the most annoying thing actually is that when the hash is wrong, the
> just-downloaded file will be removed again. It would be convenient to avoid
> removing it, similar to how it is done when the file exists already.
> 

I was thinking the same thing when write this patch. Let me see. I think it is
just another case to add in the download script.

Regards,
Gael

      reply	other threads:[~2017-10-23 12:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-20  3:18 [Buildroot] [PATCH] support/download: print dl hash if not provided Gaël PORTAY
2017-09-10  9:29 ` Yann E. MORIN
2017-09-11 19:12   ` Gaël PORTAY
2017-10-23  9:10     ` Arnout Vandecappelle
2017-10-23 12:47       ` Gaël PORTAY [this message]

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=20171023124718.zsdv7exoc3j2guim@archlinux \
    --to=gael.portay@savoirfairelinux.com \
    --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