From: Robert Yang <liezhi.yang@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [jethro][fido][PATCH 4/4] openssl: three CVE fixes
Date: Tue, 8 Dec 2015 16:14:43 +0800 [thread overview]
Message-ID: <56669173.1080901@windriver.com> (raw)
In-Reply-To: <20151208074923.GB8707@ad.chargestorm.se>
On 12/08/2015 03:49 PM, Anders Darander wrote:
> Hi,
>
> * Armin Kuster <akuster808@gmail.com> [151208 02:49]:
>
>> meta/recipes-connectivity/openssl/openssl_1.0.2d.bb | 4 ++++
>> 1 file changed, 4 insertions(+)
>
> I'm just a little curious about this serious, and a few others that I've
> seen recently. They all add a number of CVE-patches, with one commit per
> patch, and as the last commit, they all get added to SRC_URI in a single
> patch.
>
> What's the reason to do it like this? i
>
> I'd personally prefer to have each CVE-path also add the patch to
> SRC_URI, as that make cherry-picking more straightforward. And it also
> ensures that if we have a need to bisect some issue, that'll work. At
> the same time that will make the meta-data consistent, i.e. no dead
> patches.
>
> I'd personally even prefer that whole series squashed to one commit,
> compared to this adding a lot of un-applied patches.
Yes, I think that would be better.
// Robert.
>
> Any comments on this?
>
> Cheers,
> Anders
>
>> diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2d.bb b/meta/recipes-connectivity/openssl/openssl_1.0.2d.bb
>> index fd56841..3864e88 100644
>> --- a/meta/recipes-connectivity/openssl/openssl_1.0.2d.bb
>> +++ b/meta/recipes-connectivity/openssl/openssl_1.0.2d.bb
>> @@ -37,6 +37,10 @@ SRC_URI += "file://configure-targets.patch \
>> file://crypto_use_bigint_in_x86-64_perl.patch \
>> file://openssl-1.0.2a-x32-asm.patch \
>> file://ptest_makefile_deps.patch \
>> + file://CVE-2015-3193-bn-asm-x86_64-mont5.pl-fix-carry-propagating-bug-CVE.patch \
>> + file://CVE-2015-3194-1-Add-PSS-parameter-check.patch \
>> + file://0001-Add-test-for-CVE-2015-3194.patch \
>> + file://CVE-2015-3195-Fix-leak-with-ASN.1-combine.patch \
>> "
>
next prev parent reply other threads:[~2015-12-08 8:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-08 1:47 [jethro][fido][PATCH 1/4] openssl: fix for CVE-2015-3193 Armin Kuster
2015-12-08 1:47 ` [jethro][fido][PATCH 2/4] openssl: fix for CVE-2015-3194 Armin Kuster
2015-12-08 1:47 ` [jethro][fido][PATCH 3/4] openssl: fix for CVE-2015-3195 Armin Kuster
2015-12-08 1:47 ` [jethro][fido][PATCH 4/4] openssl: three CVE fixes Armin Kuster
2015-12-08 7:49 ` Anders Darander
2015-12-08 8:14 ` Robert Yang [this message]
2015-12-12 21:14 ` akuster808
2015-12-13 19:32 ` Paul Eggleton
2015-12-14 10:40 ` Anders Darander
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=56669173.1080901@windriver.com \
--to=liezhi.yang@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/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.