Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/apache: security bump version to 2.4.46
Date: Sat, 8 Aug 2020 14:23:12 +0200	[thread overview]
Message-ID: <20200808122312.GO2186@scaer> (raw)
In-Reply-To: <20200807225632.41b7c8d0@gmx.net>

Peter, All,

On 2020-08-07 22:56 +0200, Peter Seiderer spake thusly:
> On Fri, 7 Aug 2020 21:26:57 +0200, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > On 2020-08-07 19:11 +0200, Bernd Kuhls spake thusly:
> > > Changelog: http://archive.apache.org/dist/httpd/CHANGES_2.4.46
> > >
> > > Release notes: https://downloads.apache.org/httpd/Announcement2.4.html
> > >
> > > Fixes CVE-2020-9490, CVE-2020-11984 & CVE-2020-11993:
> > > https://httpd.apache.org/security/vulnerabilities_24.html
> > >
> > > Added all hashes provided by upstream.
> >
> > md5 and sha1 are broken nowadays, so adding them is not interesting at
> > all, when there are better hashes available, which is the case here.
> 
> If this handling is the new rule, then it is time to update the docs
> stating 'If upstream provides more than one type of hash (e.g. sha1 and sha512),
> then it is best to add all those hashes in the .hash file.'?

I wrote that more than 6 years ago now. ;-) Things have changed since
then.

The hashes are there to guarantee that the archives have not be tampered
with, so that we know that:

 1. there was no technical issue downloading the archive (e.g. partial
    download, proxy playing tricks, etc...),

 2. upstream did not re-release the same version with a different
    content, so that we know our patches would or would not apply for
    example,

 3. the source code has not been tampered with, so that no ill source
    code has been injected (either in-transit, or if upstream got
    compromised).

md5 is broken, there is no point in using it. If that's the only thing
upstream provides, we can carry it, but if upstream provides better
hashes, md5 brings nothing to address the above, especially point 3.

sha1 is not yet fully broken, but it is no longer trusted, and everyone
is moving away from it. If upstream only provides sha1, we can carry it,
but if upstream provides better hashes, then we should not _add_ sha1
(but we can continue to update an existing one we already carry). While
sha1 is still OK-ish to address accidental tampering (point 1) or
non-malicious modifications (point 2, and even then), it is now
useless to address malicious tampering (point 3).

This is the point of view hashes should be looked at from.

In this case, upstream provides two strong hashes, sha256 and sha512;
adding md5 is totally useless, while adding sha1 is borderline useless.

For the records:

  - md5 [0] was introduced 1991, and the first security issues were
    identified in 1993, and the first collisions reported in 1996.

  - sha1 [1] was introduced in 1995, is considered weak since 2005 (15
    years ago!), disallowed for signatures by NIST since 2013, and
    chosen-prefix attacks are a thing since this year.

[0] https://en.wikipedia.org/wiki/MD5
[1] https://en.wikipedia.org/wiki/SHA-1

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2020-08-08 12:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-07 17:11 [Buildroot] [PATCH 1/1] package/apache: security bump version to 2.4.46 Bernd Kuhls
2020-08-07 19:26 ` Yann E. MORIN
2020-08-07 20:56   ` Peter Seiderer
2020-08-08 12:23     ` Yann E. MORIN [this message]
2020-08-08 21:12       ` Peter Korsgaard
2020-08-11 21:31         ` Peter Seiderer
2020-08-28 15:04 ` 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=20200808122312.GO2186@scaer \
    --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