All of 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 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.