All of lore.kernel.org
 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 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.