Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: Bash security vulnerabilities - Question for master
Date: Thu, 2 Oct 2014 10:48:48 -0500	[thread overview]
Message-ID: <542D73E0.4050306@windriver.com> (raw)
In-Reply-To: <2071526.AGrvLGiTzH@peggleto-mobl5.ger.corp.intel.com>

On 10/2/14, 10:13 AM, Paul Eggleton wrote:
> On Thursday 02 October 2014 09:48:29 Mark Hatle wrote:
>> With the recent vulnerabilities, a bunch of patches are being sent up to the
>> list.  The content is generally fine, but I'm wondering if for master we
>> should apply all of the official bash patches to get to the latest patch
>> version, instead of applying various 'security' fixes that may or may not
>> be the official version.
>>
>> For instance, bash_4.3:
>>
>> SRC_URI = "${GNU_MIRROR}/bash/${BPN}-${PV}.tar.gz;name=tarball \
>> [followed by a bunch of local patches]
>> "
>>
>> ncftp .../bash/bash-4.3-patches > ls
>> bash43-001        bash43-004.sig    bash43-008        bash43-011.sig
>> bash43-015        bash43-018.sig    bash43-022        bash43-025.sig
>> bash43-001.sig    bash43-005        bash43-008.sig    bash43-012
>> bash43-015.sig    bash43-019        bash43-022.sig    bash43-026
>> bash43-002        bash43-005.sig    bash43-009        bash43-012.sig
>> bash43-016        bash43-019.sig    bash43-023        bash43-026.sig
>> bash43-002.sig    bash43-006        bash43-009.sig    bash43-013
>> bash43-016.sig    bash43-020        bash43-023.sig    bash43-027
>> bash43-003        bash43-006.sig    bash43-010        bash43-013.sig
>> bash43-017        bash43-020.sig    bash43-024        bash43-027.sig
>> bash43-003.sig    bash43-007        bash43-010.sig    bash43-014
>> bash43-017.sig    bash43-021        bash43-024.sig    bash43-028
>> bash43-004        bash43-007.sig    bash43-011        bash43-014.sig
>> bash43-018        bash43-021.sig    bash43-025        bash43-028.sig
>>
>> The community has 28 patches for various bugs (and these security issues)
>> posted.  Would it make sense to update to bash 4.3 (28)?
>>
>> In our bash 3.2.48:
>>
>> SRC_URI = "${GNU_MIRROR}/bash/bash-${PV}.tar.gz;name=tarball \
>>
>> ${GNU_MIRROR}/bash/bash-3.2-patches/bash32-049;apply=yes;striplevel=0;name=p
>> atch001 \
>>
>> ${GNU_MIRROR}/bash/bash-3.2-patches/bash32-050;apply=yes;striplevel=0;name=p
>> atch002 \
>>
>> ${GNU_MIRROR}/bash/bash-3.2-patches/bash32-051;apply=yes;striplevel=0;name=p
>> atch003 \
>> ...
>> "
>>
>> Some of the upstream items are applied, but I'm wondering if we should
>> extend that to patch level 55 (the latest) in the same way.
>>
>> Both patch level 4.3 - 28 and 3.2.48 - 55 will apply all of the fixes that
>> keep getting submitted plus a set of other general bugs.  It will also make
>> it easier for security scanners to simply check the version and know the
>> right fixes have been applied.
>
> FWIW, I'm inclined to agree - given the severity and high profile of these
> issues I think we should patch up to the latest patchlevel. Do we have enough
> tests to mitigate any risk of doing that for the 1.7 release, given how late
> we are in the release cycle?

I think between the ptest and normal system integration testing, we have enough 
tests to mitigate the risks.  Plus the patches themselves are heavily tested by 
the [bash] community and the official changes, so I think it's significantly 
less likely they will introduce issues.

--Mark

> Cheers,
> Paul
>



  reply	other threads:[~2014-10-02 15:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-02 14:48 Bash security vulnerabilities - Question for master Mark Hatle
2014-10-02 15:13 ` Paul Eggleton
2014-10-02 15:48   ` Mark Hatle [this message]
2014-10-02 19:06     ` Otavio Salvador

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=542D73E0.4050306@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    /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