Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Zacarias <gustavo@zacarias.com.ar>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 5/6] pkg-infra: add possiblity to check downloaded files against known hashes
Date: Wed, 15 Jan 2014 10:22:40 -0300	[thread overview]
Message-ID: <52D68BA0.6060503@zacarias.com.ar> (raw)
In-Reply-To: <52D64559.90705@mind.be>

On 01/15/2014 05:22 AM, Arnout Vandecappelle wrote:

>  If the hash file contains the following:
> 
> 486fb55c3efa71148fe07895fd713ea3a5ae343a  sha1  libfoo-1.2.3.tar.bz2
> 
> then you can now let the script check that the second field is sha1, and
> later you can support different hash methods. In that case, it is not
> necessary to update all the files when we want to switch to a new hash
> method.
> 
>  (Incidentally, it also enables Gustavo's suggestion to use whatever
> upstream provides.)

Yes.
A little explanation on why upstream hashes should be used (my mail last
night was a bit rushed out, busy busy).
When upstream releases a tarball normally it'll fire off an announcement
mail to some mailing list with (hopefully) the hash for the tarball(s).
Usually this hash(es) will also live in some project website hosting.
If the website is compromised then the hash there can also be
compromised and you are computing your hash on a bad tarball (if done
when bumping version) or an altered hash in the website.
Sent mail (mailing list archives, personal mail) is much harder to
compromise all at once hence the original hash will still be true if all
is dandy.
Of course there's the possibility that the developer machine has been
compromised or some code has been "sneaked under the carpet" with peer
review failing to notice, but then there's no hash to save you there and
it's not the intention of this either.
Regards.

  reply	other threads:[~2014-01-15 13:22 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-12 23:44 [Buildroot] [PATCH 0/6] [RFC] some download-related changes Yann E. MORIN
2014-01-12 23:44 ` [Buildroot] [PATCH 1/6] Makefile: rename USER_HOOKS_EXTRA_ENV to EXTRA_ENV Yann E. MORIN
2014-01-14 20:44   ` Arnout Vandecappelle
2014-01-12 23:44 ` [Buildroot] [PATCH 2/6] pkg-infra: move git download helper to a script Yann E. MORIN
2014-01-13 14:18   ` Luca Ceresoli
2014-01-13 17:51     ` Yann E. MORIN
2014-01-14 20:39   ` Arnout Vandecappelle
2014-01-14 22:49     ` Yann E. MORIN
2014-01-12 23:44 ` [Buildroot] [PATCH 3/6] pkg-infra: git helper creates an empty archive if PKG_VERSION is a missing hash Yann E. MORIN
2014-01-13 14:22   ` Luca Ceresoli
2014-01-13 17:50     ` Yann E. MORIN
2014-01-14 20:43   ` Arnout Vandecappelle
2014-01-14 23:21     ` Yann E. MORIN
2014-01-15  8:17       ` Arnout Vandecappelle
2014-01-17 22:35         ` Yann E. MORIN
2014-01-12 23:44 ` [Buildroot] [PATCH 4/6] package infra: DOWNLOAD is never called with two arguments Yann E. MORIN
2014-01-14 20:51   ` Arnout Vandecappelle
2014-01-12 23:44 ` [Buildroot] [PATCH 5/6] pkg-infra: add possiblity to check downloaded files against known hashes Yann E. MORIN
2014-01-13  4:53   ` Baruch Siach
2014-01-13 17:52     ` Yann E. MORIN
2014-01-14 21:37   ` Arnout Vandecappelle
2014-01-14 23:34     ` Yann E. MORIN
2014-01-15  8:22       ` Arnout Vandecappelle
2014-01-15 13:22         ` Gustavo Zacarias [this message]
2014-01-17 23:02           ` Yann E. MORIN
2014-01-18  0:33             ` Gustavo Zacarias
2014-01-17 22:41         ` Yann E. MORIN
2014-01-18 15:53           ` Luca Ceresoli
2014-01-15  0:08   ` Gustavo Zacarias
2014-01-12 23:44 ` [Buildroot] [PATCH 6/6] package/ca-certificates: add tarball's hash Yann E. MORIN
2014-01-14 21:39 ` [Buildroot] [PATCH 0/6] [RFC] some download-related changes Arnout Vandecappelle
2014-01-14 23:39   ` 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=52D68BA0.6060503@zacarias.com.ar \
    --to=gustavo@zacarias.com.ar \
    --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