Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On 05/11/2017 12:44 AM, Alexander Kanavin wrote: On 05/11/2017 12:08 AM, Khem Raj wrote: On Wed, May 10, 2017 at 1:48 PM, Davis, Michael wrote: I think most of the major distros have either switched or are in the process this year. are there some info on the policy decisions of other distros ? we should try to follow the suite then Both Fedora and Debian default to 1.1 in their upcoming versions. 1.0 is provided only as a legacy package. So same as here. I recommend members of the Yocto project to chime in as most are commercial entities and may have reasons they want Poky to stay on an LTS openssl version. OE can decide to do something different. That should be possible. Is this an OE TSC issue?? - armin Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On Fri, May 12, 2017 at 11:15 AM, Denys Dmytriyenko wrote: > On Wed, May 10, 2017 at 02:08:26PM -0700, Khem Raj wrote: >> On Wed, May 10, 2017 at 1:48 PM, Davis, Michael >> wrote: >> > I think most of the major distros have either switched or are in the >> > process >> > this year. >> > >> >> are there some info on the policy decisions of other distros ? >> we should try to follow the suite then > > Khem, > > https://wiki.debian.org/OpenSSL-1.1 > > Binary packages have X.Y version in the package name: > libssl1.1_1.1.0c-2~bpo8+1_amd64.deb > libssl1.0.0_1.0.2k-1~bpo8+1_amd64.deb > > As of OE, we've handled such updates with incompatible API in the past > similarly - gstreamer vs. gstreamer010 yes we have, my point was if were flying against the headwind or not, -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On Wed, May 10, 2017 at 02:08:26PM -0700, Khem Raj wrote: > On Wed, May 10, 2017 at 1:48 PM, Davis, Michael > wrote: > > I think most of the major distros have either switched or are in the process > > this year. > > > > are there some info on the policy decisions of other distros ? > we should try to follow the suite then Khem, https://wiki.debian.org/OpenSSL-1.1 Binary packages have X.Y version in the package name: libssl1.1_1.1.0c-2~bpo8+1_amd64.deb libssl1.0.0_1.0.2k-1~bpo8+1_amd64.deb As of OE, we've handled such updates with incompatible API in the past similarly - gstreamer vs. gstreamer010 -- Denys > > From: openembedded-core-boun...@lists.openembedded.org > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Khem > > Raj > > Sent: Wednesday, May 10, 2017 3:36 PM > > To: Alexander Kanavin; Gary Thomas; openembedded-core@lists.openembedded.org > > Subject: Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1 > > > > > > > > > > > > On Wed, May 10, 2017 at 12:34 PM Alexander Kanavin > > wrote: > > > > On 05/10/2017 09:56 PM, Gary Thomas wrote: > >> Why not do this in a "softer" way - make the new 1.1 package have the > >> obscured name (and not be preferred by default)? That way existing > >> uses of the older 1.0 package can continue but users can migrate to > >> 1.1 as they see fit? > > > > I have an answer which you might not particularly like. But here goes: > > > > What will actually happen is that no one will do anything to port their > > stuff until it's time to remove 1.0 because upstream has EOLd it. And > > then there'll still be complaints that more time is needed for the > > transition. I'd like to gently push people to plan this transition > > already now - and it's as gentle as it can be: if you pull from master > > and your things no longer build, make one simple change and they will. > > It's part and parcel of being on the bleeding edge, or rebasing to the > > new yocto release: not everything works exactly as before, and most > > components are newer and different and not always fully compatible. > > > > > > > > > > > > It is a cross distro item really we should find out what other Linux > > distributions are doing about it moving forward unless major distros also > > have same policy there won't be much momentum this would gain among the > > packages ecosystems this could also help in sharing the porting burden > > > > > > > > The other reason is that it's more work for me: I would have to update > > everything in oe-core to use the new recipe, instead of fixing just a > > few recipes that need to stay with 1.0. And then again the same thing > > will happen when 1.2 is out. > > > > Alex > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On 05/11/2017 12:08 AM, Khem Raj wrote: On Wed, May 10, 2017 at 1:48 PM, Davis, Michael wrote: I think most of the major distros have either switched or are in the process this year. are there some info on the policy decisions of other distros ? we should try to follow the suite then Both Fedora and Debian default to 1.1 in their upcoming versions. 1.0 is provided only as a legacy package. So same as here. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On Wed, May 10, 2017 at 1:48 PM, Davis, Michael wrote: > I think most of the major distros have either switched or are in the process > this year. > are there some info on the policy decisions of other distros ? we should try to follow the suite then > > > > > > > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Khem > Raj > Sent: Wednesday, May 10, 2017 3:36 PM > To: Alexander Kanavin; Gary Thomas; openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1 > > > > > > On Wed, May 10, 2017 at 12:34 PM Alexander Kanavin > wrote: > > On 05/10/2017 09:56 PM, Gary Thomas wrote: >> Why not do this in a "softer" way - make the new 1.1 package have the >> obscured name (and not be preferred by default)? That way existing >> uses of the older 1.0 package can continue but users can migrate to >> 1.1 as they see fit? > > I have an answer which you might not particularly like. But here goes: > > What will actually happen is that no one will do anything to port their > stuff until it's time to remove 1.0 because upstream has EOLd it. And > then there'll still be complaints that more time is needed for the > transition. I'd like to gently push people to plan this transition > already now - and it's as gentle as it can be: if you pull from master > and your things no longer build, make one simple change and they will. > It's part and parcel of being on the bleeding edge, or rebasing to the > new yocto release: not everything works exactly as before, and most > components are newer and different and not always fully compatible. > > > > > > It is a cross distro item really we should find out what other Linux > distributions are doing about it moving forward unless major distros also > have same policy there won't be much momentum this would gain among the > packages ecosystems this could also help in sharing the porting burden > > > > The other reason is that it's more work for me: I would have to update > everything in oe-core to use the new recipe, instead of fixing just a > few recipes that need to stay with 1.0. And then again the same thing > will happen when 1.2 is out. > > Alex > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
I think most of the major distros have either switched or are in the process this year. From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Khem Raj Sent: Wednesday, May 10, 2017 3:36 PM To: Alexander Kanavin; Gary Thomas; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1 On Wed, May 10, 2017 at 12:34 PM Alexander Kanavin mailto:alexander.kana...@linux.intel.com>> wrote: On 05/10/2017 09:56 PM, Gary Thomas wrote: > Why not do this in a "softer" way - make the new 1.1 package have the > obscured name (and not be preferred by default)? That way existing > uses of the older 1.0 package can continue but users can migrate to > 1.1 as they see fit? I have an answer which you might not particularly like. But here goes: What will actually happen is that no one will do anything to port their stuff until it's time to remove 1.0 because upstream has EOLd it. And then there'll still be complaints that more time is needed for the transition. I'd like to gently push people to plan this transition already now - and it's as gentle as it can be: if you pull from master and your things no longer build, make one simple change and they will. It's part and parcel of being on the bleeding edge, or rebasing to the new yocto release: not everything works exactly as before, and most components are newer and different and not always fully compatible. It is a cross distro item really we should find out what other Linux distributions are doing about it moving forward unless major distros also have same policy there won't be much momentum this would gain among the packages ecosystems this could also help in sharing the porting burden The other reason is that it's more work for me: I would have to update everything in oe-core to use the new recipe, instead of fixing just a few recipes that need to stay with 1.0. And then again the same thing will happen when 1.2 is out. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On Wed, May 10, 2017 at 12:34 PM Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > On 05/10/2017 09:56 PM, Gary Thomas wrote: > > Why not do this in a "softer" way - make the new 1.1 package have the > > obscured name (and not be preferred by default)? That way existing > > uses of the older 1.0 package can continue but users can migrate to > > 1.1 as they see fit? > > I have an answer which you might not particularly like. But here goes: > > What will actually happen is that no one will do anything to port their > stuff until it's time to remove 1.0 because upstream has EOLd it. And > then there'll still be complaints that more time is needed for the > transition. I'd like to gently push people to plan this transition > already now - and it's as gentle as it can be: if you pull from master > and your things no longer build, make one simple change and they will. > It's part and parcel of being on the bleeding edge, or rebasing to the > new yocto release: not everything works exactly as before, and most > components are newer and different and not always fully compatible. It is a cross distro item really we should find out what other Linux distributions are doing about it moving forward unless major distros also have same policy there won't be much momentum this would gain among the packages ecosystems this could also help in sharing the porting burden > > > The other reason is that it's more work for me: I would have to update > everything in oe-core to use the new recipe, instead of fixing just a > few recipes that need to stay with 1.0. And then again the same thing > will happen when 1.2 is out. > > Alex > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On 05/10/2017 10:53 PM, Davis, Michael wrote: Could we offload the 1.0.2 supported recipes to something similar to meta-gplv2? Then the rest of the Yocto world can move on and those that need 1.0.x can seek it out. Maybe in 2019, when 1.0.2 will be reaching EOL, but definitely not now. I don't think anyone will be happy if openssh (1.0 only for now) is removed from oe-core, and everyone has to seek an additional layer to keep that and other things running. 1.0.2 is fully supported by upstream, and they will provide bugfixes for another 2.5 years. There is nothing wrong with keeping it in oe-core, unlike the gplv2 recipes which were both badly out of date and not really getting tested. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
Could we offload the 1.0.2 supported recipes to something similar to meta-gplv2? Then the rest of the Yocto world can move on and those that need 1.0.x can seek it out. -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Alexander Kanavin Sent: Wednesday, May 10, 2017 2:34 PM To: Gary Thomas; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1 On 05/10/2017 09:56 PM, Gary Thomas wrote: > Why not do this in a "softer" way - make the new 1.1 package have the > obscured name (and not be preferred by default)? That way existing > uses of the older 1.0 package can continue but users can migrate to > 1.1 as they see fit? I have an answer which you might not particularly like. But here goes: What will actually happen is that no one will do anything to port their stuff until it's time to remove 1.0 because upstream has EOLd it. And then there'll still be complaints that more time is needed for the transition. I'd like to gently push people to plan this transition already now - and it's as gentle as it can be: if you pull from master and your things no longer build, make one simple change and they will. It's part and parcel of being on the bleeding edge, or rebasing to the new yocto release: not everything works exactly as before, and most components are newer and different and not always fully compatible. The other reason is that it's more work for me: I would have to update everything in oe-core to use the new recipe, instead of fixing just a few recipes that need to stay with 1.0. And then again the same thing will happen when 1.2 is out. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On 05/10/2017 09:56 PM, Gary Thomas wrote: Why not do this in a "softer" way - make the new 1.1 package have the obscured name (and not be preferred by default)? That way existing uses of the older 1.0 package can continue but users can migrate to 1.1 as they see fit? I have an answer which you might not particularly like. But here goes: What will actually happen is that no one will do anything to port their stuff until it's time to remove 1.0 because upstream has EOLd it. And then there'll still be complaints that more time is needed for the transition. I'd like to gently push people to plan this transition already now - and it's as gentle as it can be: if you pull from master and your things no longer build, make one simple change and they will. It's part and parcel of being on the bleeding edge, or rebasing to the new yocto release: not everything works exactly as before, and most components are newer and different and not always fully compatible. The other reason is that it's more work for me: I would have to update everything in oe-core to use the new recipe, instead of fixing just a few recipes that need to stay with 1.0. And then again the same thing will happen when 1.2 is out. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On 2017-05-10 17:38, Alexander Kanavin wrote: On 05/10/2017 06:34 PM, Davis, Michael wrote: Sitting on 2.3 wouldn't be too much an issue for me, but I can't speak for others that may be in the same situation. Do these patches / new versions require 1.1.0 or break backwards compatibility with 1.0.2? It would be nice if it could be handled by the PREFFERED_VERSION/PREFERRERED_PROVIDER. PREFERRED_ thing is not possible, unfortunately. 1.1 is API incompatible with 1.0, and so both need to be provided at the same time, with recipes explicitly telling which one they need. Most of the patchset is moving various recipes to newer, 1.1 compatible versions, so we minimize the need for 1.0. 1.0 will be provided for as long as upstream supports it, which should be another two years or so. Why not do this in a "softer" way - make the new 1.1 package have the obscured name (and not be preferred by default)? That way existing uses of the older 1.0 package can continue but users can migrate to 1.1 as they see fit? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On 05/10/2017 07:13 AM, Alexander Kanavin wrote:
This patch series introduces the recipe for openssl 1.1 (openssl 1.0 is
preserved
but renamed to openssl10), and does a few necessary adjustmenets and updates to
other
recipes. The reason it's marked RFC is that there is one known remaining issue
to
resolve: specifically, u-boot needs to be ported to 1.1 before this series can
be
merged, otherwise there's a dependency conflict when building native u-boot.
This
should be resolved quite soon, but it isn't yet (as of u-boot v2017.05).
Openssl 1.1 is an opt-out; it has the same recipe name as openssl 1.0 had, and
so
all dependencies are compiled with it by default. If there's an API issue,
please
fix it, or adjust the recipe to depend on 'openssl10' (which is a lesser
solution,
and subject to openssl 1.0 eventually being removed from oe-core).
Please review the following changes for suitability for inclusion. If you have
any objections or suggestions for improvement, please respond to the patches. If
you agree with the changes, please provide your Acked-by
Acked-by: Armin Kuster
.
The following changes since commit 381897c64069ea43d595380a3ae913bcc79cf7e1:
build-appliance-image: Update to master head revision (2017-05-01 08:56:47
+0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib akanavin/openssl-1.1
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/openssl-1.1
Alexander Kanavin (10):
python: update to 3.5.3
openssl: add a 1.1 version
u-boot-mkimage: depend on openssl 1.0
bind: fix upstream version check
bind: update to 9.10.5
openssh: depend on openssl 1.0
apr-util: add support for openssl 1.1 via backported patch
cryptodev-tests: depend on openssl 1.0
mailx: depend on openssl 1.0
gstreamer-plugins-bad: replace openssl dependency with nettle for hls
plugin
meta/conf/distro/include/no-static-libs.inc| 3 +
meta/conf/distro/include/security_flags.inc| 2 +-
meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb | 2 +-
...0001-build-use-pkg-config-to-find-libxml2.patch | 14 +-
...=> 0001-confgen-don-t-build-unix.o-twice.patch} | 17 +-
.../bind/bind/CVE-2016-1285.patch | 154 --
.../bind/bind/CVE-2016-1286_1.patch| 79 -
.../bind/bind/CVE-2016-1286_2.patch| 317 -
.../bind/bind/CVE-2016-2088.patch | 247
.../bind/bind/CVE-2016-2775.patch | 90 --
.../bind/bind/CVE-2016-2776.patch | 123
.../bind/bind/mips1-not-support-opcode.diff| 104 ---
.../bind/{bind_9.10.3-P3.bb => bind_9.10.5.bb} | 27 +-
meta/recipes-connectivity/openssh/openssh_7.4p1.bb | 3 +-
...ve-test-that-requires-running-as-non-root.patch | 49
...1-Take-linking-flags-from-LDFLAGS-env-var.patch | 43 +++
.../recipes-connectivity/openssl/openssl/run-ptest | 4 +-
.../openssl/{openssl.inc => openssl10.inc} | 14 +-
...build-with-clang-using-external-assembler.patch | 0
.../{openssl => openssl10}/Makefiles-ptest.patch | 0
.../Use-SHA256-not-MD5-as-default-digest.patch | 0
.../configure-musl-target.patch| 0
.../{openssl => openssl10}/configure-targets.patch | 0
.../debian/c_rehash-compat.patch | 0
.../openssl/{openssl => openssl10}/debian/ca.patch | 0
.../debian/debian-targets.patch| 0
.../{openssl => openssl10}/debian/man-dir.patch| 0
.../debian/man-section.patch | 0
.../{openssl => openssl10}/debian/no-rpath.patch | 0
.../debian/no-symbolic.patch | 0
.../{openssl => openssl10}/debian/pic.patch| 0
.../debian/version-script.patch| 0
.../debian1.0.2/block_digicert_malaysia.patch | 0
.../debian1.0.2/block_diginotar.patch | 0
.../debian1.0.2/version-script.patch | 0
.../engines-install-in-libdir-ssl.patch| 0
.../openssl/{openssl => openssl10}/find.pl | 0
.../fix-cipher-des-ede3-cfb1.patch | 0
.../{openssl => openssl10}/oe-ldflags.patch| 0
.../openssl-1.0.2a-x32-asm.patch | 0
...-pointer-dereference-in-EVP_DigestInit_ex.patch | 0
.../{openssl => openssl10}/openssl-c_rehash.sh | 0
.../openssl-fix-des.pod-error.patch| 0
.../openssl-util-perlpath.pl-cwd.patch | 0
.../openssl_fix_for_x32.patch | 0
.../openssl/{openssl => openssl10}/parallel.patch | 0
.../{openssl => openssl10}/ptest-deps.patch| 0
.../ptest_makefile_deps.patch | 0
.../openssl/openssl10/run-ptest| 2 +
.../{openssl => openssl10}/shared-libs.patch | 0
.../{openssl_1.0.2k.bb => op
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On 05/10/2017 06:34 PM, Davis, Michael wrote: Sitting on 2.3 wouldn't be too much an issue for me, but I can't speak for others that may be in the same situation. Do these patches / new versions require 1.1.0 or break backwards compatibility with 1.0.2? It would be nice if it could be handled by the PREFFERED_VERSION/PREFERRERED_PROVIDER. PREFERRED_ thing is not possible, unfortunately. 1.1 is API incompatible with 1.0, and so both need to be provided at the same time, with recipes explicitly telling which one they need. Most of the patchset is moving various recipes to newer, 1.1 compatible versions, so we minimize the need for 1.0. 1.0 will be provided for as long as upstream supports it, which should be another two years or so. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
Sitting on 2.3 wouldn't be too much an issue for me, but I can't speak for others that may be in the same situation. Do these patches / new versions require 1.1.0 or break backwards compatibility with 1.0.2? It would be nice if it could be handled by the PREFFERED_VERSION/PREFERRERED_PROVIDER. -Original Message- From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] Sent: Wednesday, May 10, 2017 10:16 AM To: Davis, Michael; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1 On 05/10/2017 06:02 PM, Davis, Michael wrote: > Won't this cause a lot of issues for those of us that require FIPS? > I don't think 1.1 is expected to get FIPS support for some time. https://www.openssl.org/blog/blog/2016/07/20/fips/#comment-3277656289 "There's been a delay on starting due to a priority focus on finishing the TLS 1.3 implementation; we're still waiting on a final TLS 1.3 spec. Schedule estimates are difficult, not only because we haven't actually started yet but because the FIPS 140 validation process is notoriously unpredictable. Based on the first five open source based validations I would be surprised to see a final approved validation in less than two years after we start, but my prognostications have been wrong before." Would you be okay with staying on yocto 2.3 release until this is resolved? Otherwise, this can be delayed somewhat, but "we haven't started yet; we have no idea how long it's gonna take; probably two years or more" does not seem like a reasonable ask. There are other users of oe-core, who do not care about FIPS, and at the same time do want to have 1.1. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
On 05/10/2017 06:02 PM, Davis, Michael wrote: Won't this cause a lot of issues for those of us that require FIPS? I don't think 1.1 is expected to get FIPS support for some time. https://www.openssl.org/blog/blog/2016/07/20/fips/#comment-3277656289 "There's been a delay on starting due to a priority focus on finishing the TLS 1.3 implementation; we're still waiting on a final TLS 1.3 spec. Schedule estimates are difficult, not only because we haven't actually started yet but because the FIPS 140 validation process is notoriously unpredictable. Based on the first five open source based validations I would be surprised to see a final approved validation in less than two years after we start, but my prognostications have been wrong before." Would you be okay with staying on yocto 2.3 release until this is resolved? Otherwise, this can be delayed somewhat, but "we haven't started yet; we have no idea how long it's gonna take; probably two years or more" does not seem like a reasonable ask. There are other users of oe-core, who do not care about FIPS, and at the same time do want to have 1.1. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1
Won't this cause a lot of issues for those of us that require FIPS? I don't think 1.1 is expected to get FIPS support for some time. -- Mike -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 00/10] Add openssl 1.1
This patch series introduces the recipe for openssl 1.1 (openssl 1.0 is
preserved
but renamed to openssl10), and does a few necessary adjustmenets and updates to
other
recipes. The reason it's marked RFC is that there is one known remaining issue
to
resolve: specifically, u-boot needs to be ported to 1.1 before this series can
be
merged, otherwise there's a dependency conflict when building native u-boot.
This
should be resolved quite soon, but it isn't yet (as of u-boot v2017.05).
Openssl 1.1 is an opt-out; it has the same recipe name as openssl 1.0 had, and
so
all dependencies are compiled with it by default. If there's an API issue,
please
fix it, or adjust the recipe to depend on 'openssl10' (which is a lesser
solution,
and subject to openssl 1.0 eventually being removed from oe-core).
Please review the following changes for suitability for inclusion. If you have
any objections or suggestions for improvement, please respond to the patches. If
you agree with the changes, please provide your Acked-by.
The following changes since commit 381897c64069ea43d595380a3ae913bcc79cf7e1:
build-appliance-image: Update to master head revision (2017-05-01 08:56:47
+0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib akanavin/openssl-1.1
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/openssl-1.1
Alexander Kanavin (10):
python: update to 3.5.3
openssl: add a 1.1 version
u-boot-mkimage: depend on openssl 1.0
bind: fix upstream version check
bind: update to 9.10.5
openssh: depend on openssl 1.0
apr-util: add support for openssl 1.1 via backported patch
cryptodev-tests: depend on openssl 1.0
mailx: depend on openssl 1.0
gstreamer-plugins-bad: replace openssl dependency with nettle for hls
plugin
meta/conf/distro/include/no-static-libs.inc| 3 +
meta/conf/distro/include/security_flags.inc| 2 +-
meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb | 2 +-
...0001-build-use-pkg-config-to-find-libxml2.patch | 14 +-
...=> 0001-confgen-don-t-build-unix.o-twice.patch} | 17 +-
.../bind/bind/CVE-2016-1285.patch | 154 --
.../bind/bind/CVE-2016-1286_1.patch| 79 -
.../bind/bind/CVE-2016-1286_2.patch| 317 -
.../bind/bind/CVE-2016-2088.patch | 247
.../bind/bind/CVE-2016-2775.patch | 90 --
.../bind/bind/CVE-2016-2776.patch | 123
.../bind/bind/mips1-not-support-opcode.diff| 104 ---
.../bind/{bind_9.10.3-P3.bb => bind_9.10.5.bb} | 27 +-
meta/recipes-connectivity/openssh/openssh_7.4p1.bb | 3 +-
...ve-test-that-requires-running-as-non-root.patch | 49
...1-Take-linking-flags-from-LDFLAGS-env-var.patch | 43 +++
.../recipes-connectivity/openssl/openssl/run-ptest | 4 +-
.../openssl/{openssl.inc => openssl10.inc} | 14 +-
...build-with-clang-using-external-assembler.patch | 0
.../{openssl => openssl10}/Makefiles-ptest.patch | 0
.../Use-SHA256-not-MD5-as-default-digest.patch | 0
.../configure-musl-target.patch| 0
.../{openssl => openssl10}/configure-targets.patch | 0
.../debian/c_rehash-compat.patch | 0
.../openssl/{openssl => openssl10}/debian/ca.patch | 0
.../debian/debian-targets.patch| 0
.../{openssl => openssl10}/debian/man-dir.patch| 0
.../debian/man-section.patch | 0
.../{openssl => openssl10}/debian/no-rpath.patch | 0
.../debian/no-symbolic.patch | 0
.../{openssl => openssl10}/debian/pic.patch| 0
.../debian/version-script.patch| 0
.../debian1.0.2/block_digicert_malaysia.patch | 0
.../debian1.0.2/block_diginotar.patch | 0
.../debian1.0.2/version-script.patch | 0
.../engines-install-in-libdir-ssl.patch| 0
.../openssl/{openssl => openssl10}/find.pl | 0
.../fix-cipher-des-ede3-cfb1.patch | 0
.../{openssl => openssl10}/oe-ldflags.patch| 0
.../openssl-1.0.2a-x32-asm.patch | 0
...-pointer-dereference-in-EVP_DigestInit_ex.patch | 0
.../{openssl => openssl10}/openssl-c_rehash.sh | 0
.../openssl-fix-des.pod-error.patch| 0
.../openssl-util-perlpath.pl-cwd.patch | 0
.../openssl_fix_for_x32.patch | 0
.../openssl/{openssl => openssl10}/parallel.patch | 0
.../{openssl => openssl10}/ptest-deps.patch| 0
.../ptest_makefile_deps.patch | 0
.../openssl/openssl10/run-ptest| 2 +
.../{openssl => openssl10}/shared-libs.patch | 0
.../{openssl_1.0.2k.bb => openssl10_1.0.2k.bb} | 4 +-
.../recipes-connectivity/openssl/openssl_1.1.0e.bb | 146 ++
...on3-native_3.5.2.bb => python3-native_3.
