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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox