Date   

Re: Changes that switching from smart to dnf will cause

Alexander Kanavin <alexander.kanavin@...>
 

On 02/14/2017 04:29 PM, Richard Purdie wrote:

We have situations where we simply don't know in advance if a given
postinst is going to be able to work at rootfs construction time or
not. As an example, take the fontconfig postinst. This runs under qemu
emulation. That emulation can work for some arches and not others. We
don't really want to have to mark things up to indicate which work and
which don't. Worse, some target optimisations might work and others
might not.
I found an example where qemu *is* called directly from postinst - in eudev and systemd recipes. Unfortunately, they're both broken:


pkg_postinst_eudev-hwdb () {
if test -n "$D"; then
${@qemu_run_binary(d, '$D', '${bindir}/udevadm')} hwdb --update --root $D
chown root:root $D${sysconfdir}/udev/hwdb.bin
else
udevadm hwdb --update
fi
}


If qemu fails, but chown succeeds, then the whole script will succeed, and, as a result, it will not get deferred to first boot as it should have been. You *do* need to explicitly check whether something (that may fail) did indeed fail, and if it did, then you should halt the script execution and defer to first boot.

I hope you're now closer to being convinced that this has to be fixed.


Alex


Re: Changes that switching from smart to dnf will cause

Alexander Kanavin <alexander.kanavin@...>
 

On 02/14/2017 04:29 PM, Richard Purdie wrote:

We have situations where we simply don't know in advance if a given
postinst is going to be able to work at rootfs construction time or
not. As an example, take the fontconfig postinst. This runs under qemu
emulation. That emulation can work for some arches and not others. We
don't really want to have to mark things up to indicate which work and
which don't. Worse, some target optimisations might work and others
might not.
I guess you meant the postinsts provided by fontcache.bbclass and other *cache.bbclass files? Those postinsts do not actually call qemu, and so will *not* fail in any circumstances.

What they do is call postinst_intercept with a name of different scriptlet. That will trigger an execution of this different scriptlet after all packages have been installed, and then the qemu will actually run. If that fails, *then* the original postinst is deferred to first boot.

For those who don't want to use this (rather complicated) approach, there's a more straightforward way to run things and allow them to fail. Just needs to be documented:

pkg_postinst_PACKAGE() {}
{
if D is defined: # cross-install
try_something_that_is_allowed_to_fail
if that_something_has_failed:
# this defers to first boot explicitly
# without failing the script
postinst_intercept defer_to_first_boot PACKAGE
else # target
do_something on target
}

I'd therefore like to see this change disentangled from the rpm change
and considered separately, if its something we really want to do which
I remain unconvinced about.
Sure, I can do that.

Alex


Re: Changes that switching from smart to dnf will cause

Richard Purdie
 

On Tue, 2017-02-14 at 16:04 +0200, Alexander Kanavin wrote:
6. Things that need to run on target during package installation
should 
go into pkg_postinst_ontarget()

Previously, the way to achieve this was:

pkg_postinst_PACKAGENAME() {
      if [ x"$D" = "x" ]; then
           # Actions to carry out on the device go here
      else
           exit 1
      fi
}

The new way is simply:

pkg_postinst_ontarget_PACKAGENAME() {
      # Actions to carry out on the device go here
}

The old way still works, but is deprecated and will produce a
warning. I 
understand this change is orthogonal to dnf, but the current design
is 
flawed and now is a chance to fix it. The reasons are:

1) Code is hard to read; it is not obvious that 'if D is defined
then 
exit 1' means 'defer what follows to first boot during package 
cross-install'.

2) Worse, this hides actual errors in the scriptlets; there is no 
difference between scriptlet failing because it's intended to be run
on 
target and scriptlet failing because there's a bug or a regression 
somewhere. I've already found broken scriptlets where the brokenness
was 
hidden this way (in meta-selftest/recipes-
test/postinst/postinst_1.0.bb)

Plain pkg_postinst() without special tricks works exactly as before.
I'm not sure I agree with this. I do understand your concerns however
its not quite as clear cut as you make out.

We have situations where we simply don't know in advance if a given
postinst is going to be able to work at rootfs construction time or
not. As an example, take the fontconfig postinst. This runs under qemu
emulation. That emulation can work for some arches and not others. We
don't really want to have to mark things up to indicate which work and
which don't. Worse, some target optimisations might work and others
might not.

I'd therefore like to see this change disentangled from the rpm change
and considered separately, if its something we really want to do which
I remain unconvinced about.

Cheers,

Richard


Re: Changes that switching from smart to dnf will cause

Alexander Kanavin <alexander.kanavin@...>
 

On 02/14/2017 04:08 PM, Martin Jansa wrote:
Does pkg_postinst_ontarget_PACKAGENAME() work with other package
managers like opkg?
Yes, although I have not verified this.

Alex


Re: Changes that switching from smart to dnf will cause

Martin Jansa
 

Does pkg_postinst_ontarget_PACKAGENAME() work with other package managers like opkg?

On Tue, Feb 14, 2017 at 3:04 PM, Alexander Kanavin <alexander.kanavin@...> wrote:
Hello,

I've posted the patchset for replacing the smart package manager with dnf package manager to oe-core list, and wanted to write a separate email here, laying out what are the changes this will cause and why they're necessary or good to have. Please refer to the patchset if you want to see implementation details.

1. Smart package manager is replaced by Dnf package manager. Smart has become unmaintained upstream, is not ported to Python 3.x and we need to find a replacement. Dnf is the only feasible candidate.

The change in functionality is that the on-target package management from remote package feeds is now done with a different tool that has a different set of command line options. If you have scripts that call the tool directly, or use its api (not sure if smart has an api), they need to be fixed.

2. Rpm 5.x is replaced with rpm 4.x. This is done for two major reasons:

- DNF is API incompatible with Rpm 5.x and porting it and maintaining the port is non-trivial.

- rpm 5.x itself is more or less unmaintained both in the upstream and in Yocto. There is no community around it, and Yocto is the sole remaining user. I think this is a stronger argument for moving away from it, than any technically superior features rpm 5.x may have over 4.x (not sure what those would be).

3. Berkeley db 6.x is removed; Berkeley db 5.x becomes default

Version 6.x of Berkeley DB has been rejected by open source community
due to its hostile AGPLv3 license; both Fedora and Debian are sticking with db 5.x - and by extension,all the open source projects are still developed and tested with db 5.x

In oe-core the only thing that was requiring db 6.x was rpm 5.x, and so
there's no reason to continue carrying db 6.x in oe-core. If someone needs API features that are only available in db 6.x, it can be re-added to meta-oe.

4. Createrepo is replaced with createrepo_c

createrepo_c is the current incarnation of the tool that generates remote repository metadata; it's written in C (createrepo was in Python), is faster, and is maintained.

5. architecture-independent .rpm packages are "noarch" instead of "all"

Too many places in dnf/rpm4 stack make that assumption; let's not fight against it. It's only about the filenames and the architecture tag in them; nothing else has changed in oe-core system, particularly allarch.bbclass is untouched.

6. Things that need to run on target during package installation should go into pkg_postinst_ontarget()

Previously, the way to achieve this was:

pkg_postinst_PACKAGENAME() {
     if [ x"$D" = "x" ]; then
          # Actions to carry out on the device go here
     else
          exit 1
     fi
}

The new way is simply:

pkg_postinst_ontarget_PACKAGENAME() {
     # Actions to carry out on the device go here
}

The old way still works, but is deprecated and will produce a warning. I understand this change is orthogonal to dnf, but the current design is flawed and now is a chance to fix it. The reasons are:

1) Code is hard to read; it is not obvious that 'if D is defined then exit 1' means 'defer what follows to first boot during package cross-install'.

2) Worse, this hides actual errors in the scriptlets; there is no difference between scriptlet failing because it's intended to be run on target and scriptlet failing because there's a bug or a regression somewhere. I've already found broken scriptlets where the brokenness was hidden this way (in meta-selftest/recipes-test/postinst/postinst_1.0.bb)

Plain pkg_postinst() without special tricks works exactly as before.

7. There are various rpm-related features that have not been ported over yet.

The reason is that they are all disabled by default and don't have a test case - I don't want to figure out what they're supposed to do in the absence of a clear way to verify them - there's already more than enough changes to test and review. Specifically:

- configuring remote package feeds with PACKAGE_FEED_URIS (bug to create a test case has been filed)
- signing of remote package feeds using PACKAGE_FEED_SIGN (also has a bug to create a test case)
- signing of rpm packages using RPM_SIGN_PACKAGES (this one I will fix in the next few days, as I actually did find a testcase)
- RPM_PREFER_ELF_ARCH (have no idea about what this does at all).

... and possibly other features - there's a lot of obscure corners in oe-core which I might have missed.

Regards,
Alex
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


Changes that switching from smart to dnf will cause

Alexander Kanavin <alexander.kanavin@...>
 

Hello,

I've posted the patchset for replacing the smart package manager with dnf package manager to oe-core list, and wanted to write a separate email here, laying out what are the changes this will cause and why they're necessary or good to have. Please refer to the patchset if you want to see implementation details.

1. Smart package manager is replaced by Dnf package manager. Smart has become unmaintained upstream, is not ported to Python 3.x and we need to find a replacement. Dnf is the only feasible candidate.

The change in functionality is that the on-target package management from remote package feeds is now done with a different tool that has a different set of command line options. If you have scripts that call the tool directly, or use its api (not sure if smart has an api), they need to be fixed.

2. Rpm 5.x is replaced with rpm 4.x. This is done for two major reasons:

- DNF is API incompatible with Rpm 5.x and porting it and maintaining the port is non-trivial.

- rpm 5.x itself is more or less unmaintained both in the upstream and in Yocto. There is no community around it, and Yocto is the sole remaining user. I think this is a stronger argument for moving away from it, than any technically superior features rpm 5.x may have over 4.x (not sure what those would be).

3. Berkeley db 6.x is removed; Berkeley db 5.x becomes default

Version 6.x of Berkeley DB has been rejected by open source community
due to its hostile AGPLv3 license; both Fedora and Debian are sticking with db 5.x - and by extension,all the open source projects are still developed and tested with db 5.x

In oe-core the only thing that was requiring db 6.x was rpm 5.x, and so
there's no reason to continue carrying db 6.x in oe-core. If someone needs API features that are only available in db 6.x, it can be re-added to meta-oe.

4. Createrepo is replaced with createrepo_c

createrepo_c is the current incarnation of the tool that generates remote repository metadata; it's written in C (createrepo was in Python), is faster, and is maintained.

5. architecture-independent .rpm packages are "noarch" instead of "all"

Too many places in dnf/rpm4 stack make that assumption; let's not fight against it. It's only about the filenames and the architecture tag in them; nothing else has changed in oe-core system, particularly allarch.bbclass is untouched.

6. Things that need to run on target during package installation should go into pkg_postinst_ontarget()

Previously, the way to achieve this was:

pkg_postinst_PACKAGENAME() {
if [ x"$D" = "x" ]; then
# Actions to carry out on the device go here
else
exit 1
fi
}

The new way is simply:

pkg_postinst_ontarget_PACKAGENAME() {
# Actions to carry out on the device go here
}

The old way still works, but is deprecated and will produce a warning. I understand this change is orthogonal to dnf, but the current design is flawed and now is a chance to fix it. The reasons are:

1) Code is hard to read; it is not obvious that 'if D is defined then exit 1' means 'defer what follows to first boot during package cross-install'.

2) Worse, this hides actual errors in the scriptlets; there is no difference between scriptlet failing because it's intended to be run on target and scriptlet failing because there's a bug or a regression somewhere. I've already found broken scriptlets where the brokenness was hidden this way (in meta-selftest/recipes-test/postinst/postinst_1.0.bb)

Plain pkg_postinst() without special tricks works exactly as before.

7. There are various rpm-related features that have not been ported over yet.

The reason is that they are all disabled by default and don't have a test case - I don't want to figure out what they're supposed to do in the absence of a clear way to verify them - there's already more than enough changes to test and review. Specifically:

- configuring remote package feeds with PACKAGE_FEED_URIS (bug to create a test case has been filed)
- signing of remote package feeds using PACKAGE_FEED_SIGN (also has a bug to create a test case)
- signing of rpm packages using RPM_SIGN_PACKAGES (this one I will fix in the next few days, as I actually did find a testcase)
- RPM_PREFER_ELF_ARCH (have no idea about what this does at all).

... and possibly other features - there's a lot of obscure corners in oe-core which I might have missed.

Regards,
Alex


[Job] Postdoc position available for our new FET-PROACT project

Jørgen Christian Larsen <jcla@...>
 

Postdoc position available for our new FET-PROACT project

https://ssl1.peoplexs.com/Peoplexs22/CandidatesPortalNoLogin/Vacancy.cfm?PortalID=3795&VacatureID=884160

The Embodied AI and Neurorobotics Lab (http://ens-lab.sdu.dk/), part of
Centre for BioRobotics (CBR) at the Maersk Mc-Kinney Moller Institute at
the University of Southern Denmark, is offering:

One postdoc position starting from Marts 2017 or as soon as possible
thereafter, for up to four years.

The postdoc will work on our exciting Plan4Act: “Predictive Neural
Information for Proactive Actions: From Monkey Brain to Smart House
Control” project recently funded by FET-Proactive (Area 2: Biotech for
better life) under Horizon 2020 Framework Program.

The goal of the Plan4Act project is to record and understand predictive
neural activity from monkey brain and use it to proactively control
devices in a smart house. The far-future vision behind this is to endow
motor-impaired patients with the ability to plan a daily-life goal –
like making coffee – and achieve it without having to invoke one by one
every single individual action to reach this goal.

In the context of the project, we provide the following topic for the
position:

“Embedded system technology”: You will focus on the development of a
controller board based on a field-programmable gate array (FPGA) for the
hardware implementation of the adaptive neural-based control. The
FPGA-based hardware controller will interface with a neural recording
device and a smart house. It will receive neural activities from the
monkey brain through the recording device, process the information, and
transmit final commands to a smart house.

The successful candidates will be expected to have:

1) A PhD degree in embedded system, electrical engineering and computer
science, robotics or a quantitative field.

2) Articles published in international peer-reviewed journals
documenting experience with brain machine interface, embedded systems,
FPGA systems (Design), FPGA interfacing, Neural Networks in FPGAs etc.

3) Strong background on system integration, FPGA system design, PCB
design, Circuit Design, Xilinx FPGAs, Micro Blaze, Zynq, Neural Networks
in FPGAs.

4) Good programming skills (e.g., VHDL, C, C++, Matlab Simulink).

Additionally, the candidate should have excellent writing skills and be
able to work independently. The successful candidate for the position
will be affiliated to the Embodied AI and Neurorobotics Lab at the
Maersk Mc-Kinney Moller Institute, the University of Southern Denmark.

The applicant should provide a covering letter explaining his/her
approach to the problem, and at most three articles illustrating his/her
publication record and research interests, in addition to standard items
such as CV, full publication list, etc. (see below).

Applications will be considered continuously until the position is filled.

Contact Information: Further information is available from Assistant
Prof. Jørgen Christian Larsen, email jcla@...

Research environment: Please see http://ens-lab.sdu.dk/contact/ for the
location of the Embodied AI and Neurorobotics Lab.

To get a better idea of related research, please visit
http://ens-lab.sdu.dk/

Application, salary and conditions of employment etc.
Employment as postdoc is temporary. Level of qualification is a PhD.

If special circumstances exist employment may be extended for one year.

Research will be predominant in the position. Teaching assignments can
be agreed individually. Furthermore, other types of assignments may
occur to a limited degree.

The Faculty determines the distribution of the various assignments. The
weighting of the different assignments may vary over time.

Applications will be assessed by an expert. Applicants will be informed
of their assessment by the Faculty.

As part of the overall assessment of the applicant’s qualifications, an
interview may be applied.

The successful applicant will be employed in accordance with the
agreement between the Ministry of Finance and AC (the Danish
Confederation of Professional Associations), Cirkulære om overenskomst
for Akademikere i staten 2015.

Applications must be submitted electronically using the link below.
Attached files must be in Adobe PDF or Word format. Each box can only
contain a single file of max. 10 Mb.

An application must include:

Application
Curriculum Vitae
Certificates/Diplomas (Master and PhD degree)
Information on previous teaching experience, please attach as Teaching
portfolio
List of publications indicating the publications attached
Examples of the most relevant publications. Please attach one pdf-file
for each publication, a possible co-author statement must be a part of
this pdf-file
Further information for international applicants about entering and
working in Denmark.

The University encourages all interested persons to apply, regardless of
age, gender, religious affiliation or ethnic background.


Campus:
Odense


Application deadline:
27/02/2017

Apply online:
https://ssl1.peoplexs.com/Peoplexs22/CandidatesPortalNoLogin/ApplicationForm.cfm?PortalID=3795&VacatureID=884160

--
Jørgen Christial Larsen, Ph.D
Assistant Professor
The Maersk Mc-Kinney Moller Institute
University of Southern Denmark


Re: Default opkg solver backend change to libsolv

Alejandro del Castillo <alejandro.delcastillo@...>
 

On 02/01/2017 11:05 AM, Khem Raj wrote:
Static codesize it one aspect, it will also be interesting to know the
runtime memory requirements changes due to this. Since that could also
be a concern for systems using opkg.
I just realized that my disk footprints where off. The actual libsolv
footprint is about 3 times my original estimate. Here are the correct
metrics:

========================
Disk Footprint
========================
qemux86-64 523K
qemuarm 445K
qemux86 576K

For memory footprint, I profiled a few commands high memory watermark
via valgrind [1], with feeds containing ~18K packages:

====================================================
Command Libsolv Internal Solver
=====================================================
opkg update 26.21 MB 26.21 MB
opkg list 29.87 MB 29.87 MB
opkg install procps 30.99 MB 27.33 MB
opkg remove procps 1.69 MB 1.69 MB
opkg update 30.97 MB 27.75 MB

Libsolv increases memory usage by ~14% in the install & upgrade case.
This makes sense to me since opkg first creates internal structures for
all installed & available packages, then moves that information into
libsolv's structures, before calling the solver. A future optimization
could fill the libsolv structures directly.

[1] valgrind --tool=massif <command>
--
Cheers,

Alejandro


Re: [OE-core] OpenEmbedded Stand at FOSDEM

Philip Balister
 

On 02/02/2017 06:01 PM, Andreas Müller wrote:
On Fri, Jan 27, 2017 at 8:44 AM, Paul Barker <paul@...> wrote:

There's 3 of us from Togán Labs who'll be able to help out manning the
stand. I know I can do all day Saturday and up to about 4pm on Sunday
and I'm happy to be at the stand all day (with the obvious caffeine
breaks!). Let me know if you need help setting things up and what time
you need people to turn up on Saturday morning.
I try to be there at 9:00 (have ~3h by car) - anybody there then?
SDR devroom starts at 1030, I'll try and be at the stand before then.
Beer event willing.

Philip


Andreas


Re: [OE-core] OpenEmbedded Stand at FOSDEM

Andreas Müller <schnitzeltony@...>
 

On Fri, Jan 27, 2017 at 8:44 AM, Paul Barker <paul@...> wrote:

There's 3 of us from Togán Labs who'll be able to help out manning the
stand. I know I can do all day Saturday and up to about 4pm on Sunday
and I'm happy to be at the stand all day (with the obvious caffeine
breaks!). Let me know if you need help setting things up and what time
you need people to turn up on Saturday morning.
I try to be there at 9:00 (have ~3h by car) - anybody there then?

Andreas


Re: Default opkg solver backend change to libsolv

Khem Raj
 

On 1/30/17 3:17 PM, Alejandro del Castillo wrote:
Before opkg 0.3.1, dependency solving was performed exclusively by an
internal recursive ad-hoc solver implementation. On version 0.3.1, an
alternative external solver backend was introduced, based on libsolv
[1]. Libsolv is a SAT solver library for package dependencies, faster
and vastly superior than opkg's internal solver. It's already the solver
behind Zypper and DMF.

On the current opkg release (0.3.4), I think the backend has had enough
runtime, and is robust enough to be used as the default on OE. Opkg
bugzilla tickets overwhelmingly are on the internal solver (internalsolv
tag) [2] and we can all benefit from moving away from it.

The only feature missing on the libsolv backend is support for "opkg
list-upgradable". I looked at the OE code and I believe the feature is
not being used. However, if this is a major issue, please speak up, as
there is an in-work changeset that implements support, which I could
make sure is included before the switch (if approved).

The other side-effect would be an increase of the disk footprint, due to
the dependency on libsolv. The increase amounts to < 200K for a few
platforms that I profiled:

x64 171K
qemuarm 141K
qemux86 184K

I want to put this proposal up for comments to see if everyone is OK
with the switch.

[1] https://github.com/openSUSE/libsolv
[2]
https://bugzilla.yoctoproject.org/buglist.cgi?product=opkg&component=opkg&resolution=---&list_id=591616
Static codesize it one aspect, it will also be interesting to know the
runtime memory requirements changes due to this. Since that could also
be a concern for systems using opkg.


Re: Yocto post-release CVE and package uprev policy - openssl, ffmpeg, etc.

Alexander Kanavin <alexander.kanavin@...>
 

On 01/31/2017 12:08 AM, Randy MacLeod wrote:
Well, I expected such a reply but hoped to be surprised. It's a
tough call as a distro maintainer. I wonder if maintainers for other
major distros would generally have the same concerns about lack of time
to develop the required expertise or is Yocto different due to lack of
community participation.
I think it's a bit easier for desktop distros. The upstream developers have to use some kind of desktop Linux, and then it's natural that they would be supporting their distro in packaging and updating their code correctly. Or they would even directly maintain the packaging. Not so for Yocto; upstreams have no personal incentive to help us.

We do learn some of the upstream code piece-meal, but it's incidental, and happens when there's a specific task to be solved; for instance I know almost everything about gobject introspection :) and I can imagine Jussi knows quite a bit about the parts of gtk+3 that are relevant to sato desktop. When I'll be updating openssl to 1.1 (in itself a non-trivial task [1]), I can imagine I'll be more knowledgeable about the API breakage they caused, and how it should be fixed - but not any other parts.

[1] http://lists.openembedded.org/pipermail/openembedded-core/2016-December/130132.html

Alex


Re: Default opkg solver backend change to libsolv

Alexander Kanavin <alexander.kanavin@...>
 

On 01/31/2017 02:14 PM, Burton, Ross wrote:

I want to put this proposal up for comments to see if everyone is OK
with the switch.


I for one endorse this plan. Solving isn't trivial, so sharing code is
wise.
Also, the upcoming dnf repo manager is also using libsolv. So any bugs and issues will at least be consistent across packaging backends :)

Alex


Re: Default opkg solver backend change to libsolv

Burton, Ross <ross.burton@...>
 


On 30 January 2017 at 23:17, Alejandro del Castillo <alejandro.delcastillo@...> wrote:
I want to put this proposal up for comments to see if everyone is OK
with the switch.

I for one endorse this plan.  Solving isn't trivial, so sharing code is wise.

Ross


Default opkg solver backend change to libsolv

Alejandro del Castillo <alejandro.delcastillo@...>
 

Before opkg 0.3.1, dependency solving was performed exclusively by an
internal recursive ad-hoc solver implementation. On version 0.3.1, an
alternative external solver backend was introduced, based on libsolv
[1]. Libsolv is a SAT solver library for package dependencies, faster
and vastly superior than opkg's internal solver. It's already the solver
behind Zypper and DMF.

On the current opkg release (0.3.4), I think the backend has had enough
runtime, and is robust enough to be used as the default on OE. Opkg
bugzilla tickets overwhelmingly are on the internal solver (internalsolv
tag) [2] and we can all benefit from moving away from it.

The only feature missing on the libsolv backend is support for "opkg
list-upgradable". I looked at the OE code and I believe the feature is
not being used. However, if this is a major issue, please speak up, as
there is an in-work changeset that implements support, which I could
make sure is included before the switch (if approved).

The other side-effect would be an increase of the disk footprint, due to
the dependency on libsolv. The increase amounts to < 200K for a few
platforms that I profiled:

x64 171K
qemuarm 141K
qemux86 184K

I want to put this proposal up for comments to see if everyone is OK
with the switch.

[1] https://github.com/openSUSE/libsolv
[2]
https://bugzilla.yoctoproject.org/buglist.cgi?product=opkg&component=opkg&resolution=---&list_id=591616

--
Cheers,

Alejandro


-- >8 --
Subject: [PATCH] opkg: enable libsolv backend by default

The libsolv backend is vastly superior than the currently enabled
internal ad-hoc solver. This change adds a dependency on libsolv, which
has an impact on footprint:

x64 171K
qemuarm 141K
qemux86 184K

Signed-off-by: Alejandro del Castillo <alejandro.delcastillo@...>
---
meta/recipes-devtools/opkg/opkg_0.3.4.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/opkg/opkg_0.3.4.bb
b/meta/recipes-devtools/opkg/opkg_0.3.4.bb
index 6ac9438..e298185 100644
--- a/meta/recipes-devtools/opkg/opkg_0.3.4.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.3.4.bb
@@ -28,7 +28,7 @@ SYSTEMD_SERVICE_${PN} = "opkg-configure.service"
target_localstatedir := "${localstatedir}"
OPKGLIBDIR = "${target_localstatedir}/lib"

-PACKAGECONFIG ??= ""
+PACKAGECONFIG ??= "libsolv"

PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,gpgme libgpg-error,gnupg"
PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
--
2.7.4


Re: Yocto post-release CVE and package uprev policy - openssl, ffmpeg, etc.

Armin Kuster
 

On 01/30/2017 09:31 AM, Mark Hatle wrote:
On 1/30/17 10:45 AM, akuster808 wrote:

On 01/26/2017 12:10 PM, Randy MacLeod wrote:
Yocto seems to have a policy not to update packages once a
release is generally available.
I believe this is already covered in the current policy.

(lifted from policy)
No recipe upgrades unless:
The new version contains a security patch or other critical bugfix that
is too difficult to backport to the version already in the stable branch.

does that not cover this concern?
No. The issue is that there are other non-security fixes that are roughly being
ignored. And we often get a lot of the "why aren't you on version XYZ of
OpenSSL" type questions.
The reply should be "Hey, send a patch".


Doesn't matter if it's up-to-date or not, they're convinced by their 'security
scanning software' that anything it says 'might' have a problem -does- have a
problem.
We will never get around that issue.


As others have indicate the worry is always around the APIs. They change and it
screws up everything else.

(there is also a secondary issue of... it's easier to just jump versions, then
backport fixes and verify the fixes are working...)
The depends on the package. If there are any pending upstream patches, those may need to be ported forward if not included in the update.

- armin

--Mark


I think that rule should be
broken for certain packages that have been reviewed and tested
properly.
To me the responsibility is on the person who wants for issue fixed via
a package update. They need to convince the package maintainer or branch
maintainer that this is the better course of action than to back port a
patch.
See:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10707
for additional background.

For some packages, the upstream development team fixes CVE and
other bugs on their released version and by YP only cherry-picking back
specific fixes, we expose users to additional risk and incur higher
costs of maintenance. At least two packages that I know of have released
"bug fix only" updates to fix CVEs and other defects for packages
that are in morty:

- openssl 1.0.2j -> 1.0.2k
- ffmpeg 3.1.3 -> 3.1.5
Gcc, Glibc and kernel fall into this bucket too so where do you draw the
line?

Should we continue to cherry-pick back only the CVEs fixes
or should we review, test, and release the full minor release?
My preference is to improve the guidelines rather than creating
exceptions. There is the scenario that if a CVE fix exists and no new
package version has been released, we should wait.

It not uncommon for a commit message to a package upgrade lacks
information to help a stable branch maintainer make a decision for
backporting.

I've done a review of openssl below but
before I proceed with more evaluation or sending the
uprev to the list for morty, I'd like to know if the upgrade
policy will block such a change. From my analysis, there's only
one change that seems like an upgrade blocker and I need help
to evaluate that since I'm not an openssl maintainer.


I've done the upgrade locally. It's just a few lines and builds
seem to be fine so far. I'll send the upgrade for master
at least once my builds complete and I've done some other
tests.
Then send patches and explain why. The maintainer of the stable branch
appears to be some what reasonable and does appreciate all input on what
should be back ported to the stable branches.

Regards,
Armin

../Randy


Review of openssl-1.0.2j->k.


Early next week, I'll check for an update on: 1.0.2j->k compatibility
here:
https://abi-laboratory.pro/tracker/timeline/openssl/
'k' hasn't been done as of Jan 26th.


I looked at the 78 changes to openssl-1.0.2j->k and
found that 4 header files had changed. Here's a list of
the header files and my conclusion/summary.

$ git diff OpenSSL_1_0_2j..OpenSSL_1_0_2k | \
diffstat| grep "\.h"
apps/apps.h | 4
--> Add: always call setup_engine
crypto/evp/evp.h | 6
--> +# define EVP_R_INVALID_KEY and whitespace
crypto/opensslv.h | 6
--> version update
ssl/ssl_locl.h | 2
--> api change but according to [1] it's an internal header
-int ssl_check_clienthello_tlsext_late(SSL *s);
+int ssl_check_clienthello_tlsext_late(SSL *s, int *al);


[1] Mr Burton claims this is (or was?) a private api:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641711


The change to always call setup_engine() may be a problem
but I'm not familiar with the openssl code base so I'm
not sure how big a deal it is. Alex, are you familiar with
this part of openssl?


Here is a list of the commits:

$ git log --oneline OpenSSL_1_0_2j..OpenSSL_1_0_2k | wc -l
78

$ git log --oneline OpenSSL_1_0_2j..OpenSSL_1_0_2k

081314d Prepare for 1.0.2k release
06f87e9 Update CHANGES and NEWS for new release
918d8ea Better check of DH parameters in TLS data
760d043 bn/asm/x86_64-mont5.pl: fix carry bug in bn_sqr8x_internal.
51d0090 crypto/evp: harden RC4_MD5 cipher.
8957add Fix error handling in compute_key, BN_CTX_get can return NULL
cb00d4f Fix a ssl session leak due to OOM in lh_SSL_SESSION_insert
e203f49 Fix SSL_VERIFY_CLIENT_ONCE
149e98d Add missing va_end
16f013f Fix DSA parameter generation control error
52b703f Clean one unused variable, plus an useless one.
1f234f7 GH1986: Document -header flag.
0ecb682 Fix error handling in SSL_CTX_new
2045c58 Fix a memory leak in RSA_padding_add_PKCS1_OAEP_mgf1
18b8431 replace "will lookup up" by "will look up"
58c81e7 Reformat M_check_autoarg to match our coding style
222333c M_check_autoarg: sanity check the key
3fb9f87 Fix typo.
5bbedd3 zero pad DHE public key in ServerKeyExchange message for interop
70705b2 Fix ssl_cert_dup: change one 'return NULL' to 'goto err'
3b584ef Make 'err' lable in ssl_cert_dup unconditional
292bb56 Fix a bug in clienthello processing
7624a31 perlasm/x86_64-xlate.pl: refine sign extension in ea package.
10a5037 UI_OpenSSL()'s session opener fails on MacOS X
78a3e80 VMS UI_OpenSSL:
if the TT device isn't a tty, flag instead of error
fecd4c2 Check input length to pkey_rsa_verify()
5ae285e Remove extra bang
59ba83c UI code style cleanup
748a2d9 Revert "Fix heartbeat_test"
be3a7dd apps/speed.c: Fix crash when config loading fails
c477f8e INSTALL: clarify 386 and no-sse2 options.
f47201b modes/ctr128.c: fix false carry in counter increment procedure.
c4c7165 Clarify what X509_NAME_online does with
the given buffer and size
31b4307 Make SSL_read and SSL_write return
the old behaviour and document it.
09b894b Use consistent variable names
f4ef1c5 domd: Preserve Makefile time when it is unchanged
7a9d712 mklink: Do not needlessly overwrite linked files...
62f16de domd: Do not needlessly overwrite Makefiles
22cc44d mklink: Do not needlessly overwrite linked files...
ecc9551 Configure: Improve incremental build time
8ac70be Check return value of some BN functions.
3201a1d Solution proposal for issue #1647.
19e1de5 Update CHANGES and NEWS
57c4b9f bn/asm/x86_64-mont.pl: fix for CVE-2016-7055 (Low severity).
c210840 Makefile.org: clear APPS environment variable.
95873c5 Missed a mention of RT
563a34e Add a CHANGES entry for the unrecognised record type change
f118539 Fail if an unrecognised record type is received
ad69a30 Fix heartbeat_test
ba2bf83 Secure our notification email.
e022375 Fix grammar-o in CONTRIBUTING
787b2dc Add $(EX_LIBS) to the LIBDEPS for libgost.so,
just as for all other engines
0b9c5da Implement length checks as a macro
a520723 Ensure we have length checks for all extensions
83a1d4b Fix length check writing status request extension
57aa2f1 Fix a double free in ca command line
fa4c374 A zero return from BIO_read/BIO_write() could be retryable
31bf65c Fix typo (reported by Matthias St. Pierre)
0e46901 Fix leak of secrecy in ecdh_compute_key()
3ade92e Correctly find all critical CRL extensions
45f4761 remove redundant zero assignments
cdb203f %p takes void*, so make sure to cast arguments to void*
0df1caa apps: make setup_engine() and release_engine() available always
aa01b82 If an engine comes up explicitely,
it must also come down explicitely
10e60f2 Fix no-des
1c6aab6 Make 'openssl prime ""' not segfault
99c002b Fix strict-warnings build
b0161f6 Fix strict-warnings build
78ee64c Fix signatures of EVP_Digest{Sign,Verify}Update
02a0231 Ensure we handle len == 0 in ERR_err_string_n
6d69dc5 Degrade 3DES to MEDIUM in SSL2
e8e380c RT is put out to pasture
f1f9769 Add missing error string for SSL_R_TOO_MANY_WARN_ALERTS
53a71b7 apps/apps.c: initialize and de-initialize engine
around key loading
a269e5f Revert "Call ENGINE_init() before trying to use keys
from engine"
4badd2b Call ENGINE_init() before trying to use keys from engine
9702bf5 Fix NEWS error
f6e43fe Prepare for 1.0.2k-dev


I've look at any commits that *seem* like they could be more than
a bug fix or that might change the api. Aside from the two issues
related to header files, I didn't see anything to worry about.

$ git diff OpenSSL_1_0_2j..OpenSSL_1_0_2k | diffstat
.travis.yml | 2
CHANGES | 61 ++++++
CONTRIBUTING | 55 +----
Configure | 34 ++-
INSTALL | 69 +++---
Makefile.org | 3
NEWS | 8
README | 36 ---
apps/apps.c | 19 +
apps/apps.h | 4
apps/ca.c | 6
apps/cms.c | 5
apps/dgst.c | 1
apps/dh.c | 6
apps/dhparam.c | 8
apps/dsa.c | 7
apps/dsaparam.c | 8
apps/ec.c | 6
apps/ecparam.c | 10
apps/enc.c | 8
apps/gendh.c | 4
apps/gendsa.c | 8
apps/genpkey.c | 2
apps/genrsa.c | 7
apps/pkcs12.c | 7
apps/pkcs7.c | 8
apps/pkcs8.c | 5
apps/pkey.c | 5
apps/pkeyparam.c | 8
apps/pkeyutl.c | 1
apps/prime.c | 12 -
apps/rand.c | 8
apps/req.c | 5
apps/rsa.c | 5
apps/rsautl.c | 5
apps/s_cb.c | 4
apps/s_client.c | 7
apps/s_server.c | 7
apps/smime.c | 5
apps/speed.c | 14 -
apps/spkac.c | 5
apps/srp.c | 8
apps/verify.c | 5
apps/x509.c | 5
crypto/aes/asm/aes-s390x.pl | 8
crypto/asn1/p5_pbev2.c | 8
crypto/asn1/x_crl.c | 3
crypto/bn/asm/x86_64-mont.pl | 5
crypto/bn/asm/x86_64-mont5.pl | 16 -
crypto/bn/bn_exp.c | 5
crypto/bn/bn_mul.c | 5
crypto/bn/bn_prime.c | 3
crypto/bn/bn_sqr.c | 5
crypto/cms/cms_kari.c | 5
crypto/dh/dh_key.c | 2
crypto/dsa/dsa_pmeth.c | 2
crypto/ec/ec2_mult.c | 20 +
crypto/ecdh/ech_ossl.c | 4
crypto/err/err.c | 3
crypto/evp/e_aes.c | 4
crypto/evp/e_rc4_hmac_md5.c | 2
crypto/evp/evp.h | 6
crypto/evp/evp_err.c | 3
crypto/evp/pmeth_fn.c | 30 +-
crypto/evp/pmeth_lib.c | 28 --
crypto/modes/ctr128.c | 2
crypto/opensslv.h | 6
crypto/perlasm/x86_64-xlate.pl | 11 -
crypto/rsa/rsa_gen.c | 3
crypto/rsa/rsa_oaep.c | 8
crypto/rsa/rsa_pmeth.c | 4
crypto/s390xcap.c | 1
crypto/ui/ui_lib.c | 138 +++++++------
crypto/ui/ui_openssl.c | 59 +++--
demos/easy_tls/easy-tls.c | 1
doc/apps/ocsp.pod | 9
doc/crypto/EVP_DigestSignInit.pod | 2
doc/crypto/EVP_DigestVerifyInit.pod | 2
doc/crypto/RSA_generate_key.pod | 2
doc/crypto/X509_NAME_get_index_by_NID.pod | 3
doc/crypto/X509_NAME_print_ex.pod | 8
doc/ssl/SSL_CTX_set_session_cache_mode.pod | 2
doc/ssl/SSL_get_error.pod | 22 --
doc/ssl/SSL_read.pod | 32 +--
doc/ssl/SSL_write.pod | 19 -
engines/ccgost/Makefile | 2
openssl.spec | 2
ssl/bad_dtls_test.c | 5
ssl/s23_pkt.c | 12 -
ssl/s2_lib.c | 2
ssl/s2_pkt.c | 10
ssl/s3_clnt.c | 44 +++-
ssl/s3_pkt.c | 23 +-
ssl/s3_srvr.c | 33 ++-
ssl/ssl_cert.c | 4
ssl/ssl_err.c | 1
ssl/ssl_lib.c | 4
ssl/ssl_locl.h | 2
ssl/ssl_sess.c | 9
ssl/t1_lib.c | 291
++++++++++++++++++-----------
util/domd | 11 -
util/mklink.pl | 8
102 files changed, 836 insertions(+), 634 deletions(-)



_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


Re: Yocto post-release CVE and package uprev policy - openssl, ffmpeg, etc.

Randy MacLeod
 

On 2017-01-30 12:43 PM, Khem Raj wrote:


On 1/30/17 9:31 AM, Mark Hatle wrote:
On 1/30/17 10:45 AM, akuster808 wrote:


On 01/26/2017 12:10 PM, Randy MacLeod wrote:

Yocto seems to have a policy not to update packages once a
release is generally available.
I believe this is already covered in the current policy.

(lifted from policy)
No recipe upgrades unless:
The new version contains a security patch or other critical bugfix that
is too difficult to backport to the version already in the stable branch.

does that not cover this concern?
No. The issue is that there are other non-security fixes that are roughly being
ignored. And we often get a lot of the "why aren't you on version XYZ of
OpenSSL" type questions.

Doesn't matter if it's up-to-date or not, they're convinced by their 'security
scanning software' that anything it says 'might' have a problem -does- have a
problem.
I am aware of such tools which do version matching and slap a list of
CVEs at you without knowing anything else about the software. It would
be more useful if these software really looked at a given CVE and
detected that provided fix has been applied. I am not sure if this
should be a motivation for changing the policy. Moreover it does not end
with openssl, there is libcurl, libpng, freetype you name it, its an
endless list. So we could contemplate a move to rolling release model
or we could define a semi-rolling release model which definitely
involves more testing effort in point releases.


As others have indicate the worry is always around the APIs. They change and it
screws up everything else.

(there is also a secondary issue of... it's easier to just jump versions, then
backport fixes and verify the fixes are working...)
It might be easier build time, I dont think it changes runtime test matrix

it will be interesting to know what do other distros which do time based
releases as well do in such regard. e.g. centos, debian.

F25 is still on openssl-1.0.2j and from the one person who replied
on freenode #fedora, there don't seem to be any plans to upgrade.

The ABI checker site has check on 1.0.2k and claims:
Backward Compatibility = 100%
Added Symbols = Removed Symbols = 0;

https://abi-laboratory.pro/tracker/timeline/openssl/



Thanks for the comments everyone.

I'll drop the issue and bring it up again should the project have
sufficient participation to consider investing in a different workflow.

../Randy






--Mark


I think that rule should be
broken for certain packages that have been reviewed and tested
properly.
To me the responsibility is on the person who wants for issue fixed via
a package update. They need to convince the package maintainer or branch
maintainer that this is the better course of action than to back port a
patch.

See:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10707
for additional background.

For some packages, the upstream development team fixes CVE and
other bugs on their released version and by YP only cherry-picking back
specific fixes, we expose users to additional risk and incur higher
costs of maintenance. At least two packages that I know of have released
"bug fix only" updates to fix CVEs and other defects for packages
that are in morty:

- openssl 1.0.2j -> 1.0.2k
- ffmpeg 3.1.3 -> 3.1.5
Gcc, Glibc and kernel fall into this bucket too so where do you draw the
line?

Should we continue to cherry-pick back only the CVEs fixes
or should we review, test, and release the full minor release?
My preference is to improve the guidelines rather than creating
exceptions. There is the scenario that if a CVE fix exists and no new
package version has been released, we should wait.

It not uncommon for a commit message to a package upgrade lacks
information to help a stable branch maintainer make a decision for
backporting.


I've done a review of openssl below but
before I proceed with more evaluation or sending the
uprev to the list for morty, I'd like to know if the upgrade
policy will block such a change. From my analysis, there's only
one change that seems like an upgrade blocker and I need help
to evaluate that since I'm not an openssl maintainer.


I've done the upgrade locally. It's just a few lines and builds
seem to be fine so far. I'll send the upgrade for master
at least once my builds complete and I've done some other
tests.
Then send patches and explain why. The maintainer of the stable branch
appears to be some what reasonable and does appreciate all input on what
should be back ported to the stable branches.

Regards,
Armin


../Randy


Review of openssl-1.0.2j->k.


Early next week, I'll check for an update on: 1.0.2j->k compatibility
here:
https://abi-laboratory.pro/tracker/timeline/openssl/
'k' hasn't been done as of Jan 26th.


I looked at the 78 changes to openssl-1.0.2j->k and
found that 4 header files had changed. Here's a list of
the header files and my conclusion/summary.

$ git diff OpenSSL_1_0_2j..OpenSSL_1_0_2k | \
diffstat| grep "\.h"
apps/apps.h | 4
--> Add: always call setup_engine
crypto/evp/evp.h | 6
--> +# define EVP_R_INVALID_KEY and whitespace
crypto/opensslv.h | 6
--> version update
ssl/ssl_locl.h | 2
--> api change but according to [1] it's an internal header
-int ssl_check_clienthello_tlsext_late(SSL *s);
+int ssl_check_clienthello_tlsext_late(SSL *s, int *al);


[1] Mr Burton claims this is (or was?) a private api:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641711


The change to always call setup_engine() may be a problem
but I'm not familiar with the openssl code base so I'm
not sure how big a deal it is. Alex, are you familiar with
this part of openssl?


Here is a list of the commits:

$ git log --oneline OpenSSL_1_0_2j..OpenSSL_1_0_2k | wc -l
78

$ git log --oneline OpenSSL_1_0_2j..OpenSSL_1_0_2k

081314d Prepare for 1.0.2k release
06f87e9 Update CHANGES and NEWS for new release
918d8ea Better check of DH parameters in TLS data
760d043 bn/asm/x86_64-mont5.pl: fix carry bug in bn_sqr8x_internal.
51d0090 crypto/evp: harden RC4_MD5 cipher.
8957add Fix error handling in compute_key, BN_CTX_get can return NULL
cb00d4f Fix a ssl session leak due to OOM in lh_SSL_SESSION_insert
e203f49 Fix SSL_VERIFY_CLIENT_ONCE
149e98d Add missing va_end
16f013f Fix DSA parameter generation control error
52b703f Clean one unused variable, plus an useless one.
1f234f7 GH1986: Document -header flag.
0ecb682 Fix error handling in SSL_CTX_new
2045c58 Fix a memory leak in RSA_padding_add_PKCS1_OAEP_mgf1
18b8431 replace "will lookup up" by "will look up"
58c81e7 Reformat M_check_autoarg to match our coding style
222333c M_check_autoarg: sanity check the key
3fb9f87 Fix typo.
5bbedd3 zero pad DHE public key in ServerKeyExchange message for interop
70705b2 Fix ssl_cert_dup: change one 'return NULL' to 'goto err'
3b584ef Make 'err' lable in ssl_cert_dup unconditional
292bb56 Fix a bug in clienthello processing
7624a31 perlasm/x86_64-xlate.pl: refine sign extension in ea package.
10a5037 UI_OpenSSL()'s session opener fails on MacOS X
78a3e80 VMS UI_OpenSSL:
if the TT device isn't a tty, flag instead of error
fecd4c2 Check input length to pkey_rsa_verify()
5ae285e Remove extra bang
59ba83c UI code style cleanup
748a2d9 Revert "Fix heartbeat_test"
be3a7dd apps/speed.c: Fix crash when config loading fails
c477f8e INSTALL: clarify 386 and no-sse2 options.
f47201b modes/ctr128.c: fix false carry in counter increment procedure.
c4c7165 Clarify what X509_NAME_online does with
the given buffer and size
31b4307 Make SSL_read and SSL_write return
the old behaviour and document it.
09b894b Use consistent variable names
f4ef1c5 domd: Preserve Makefile time when it is unchanged
7a9d712 mklink: Do not needlessly overwrite linked files...
62f16de domd: Do not needlessly overwrite Makefiles
22cc44d mklink: Do not needlessly overwrite linked files...
ecc9551 Configure: Improve incremental build time
8ac70be Check return value of some BN functions.
3201a1d Solution proposal for issue #1647.
19e1de5 Update CHANGES and NEWS
57c4b9f bn/asm/x86_64-mont.pl: fix for CVE-2016-7055 (Low severity).
c210840 Makefile.org: clear APPS environment variable.
95873c5 Missed a mention of RT
563a34e Add a CHANGES entry for the unrecognised record type change
f118539 Fail if an unrecognised record type is received
ad69a30 Fix heartbeat_test
ba2bf83 Secure our notification email.
e022375 Fix grammar-o in CONTRIBUTING
787b2dc Add $(EX_LIBS) to the LIBDEPS for libgost.so,
just as for all other engines
0b9c5da Implement length checks as a macro
a520723 Ensure we have length checks for all extensions
83a1d4b Fix length check writing status request extension
57aa2f1 Fix a double free in ca command line
fa4c374 A zero return from BIO_read/BIO_write() could be retryable
31bf65c Fix typo (reported by Matthias St. Pierre)
0e46901 Fix leak of secrecy in ecdh_compute_key()
3ade92e Correctly find all critical CRL extensions
45f4761 remove redundant zero assignments
cdb203f %p takes void*, so make sure to cast arguments to void*
0df1caa apps: make setup_engine() and release_engine() available always
aa01b82 If an engine comes up explicitely,
it must also come down explicitely
10e60f2 Fix no-des
1c6aab6 Make 'openssl prime ""' not segfault
99c002b Fix strict-warnings build
b0161f6 Fix strict-warnings build
78ee64c Fix signatures of EVP_Digest{Sign,Verify}Update
02a0231 Ensure we handle len == 0 in ERR_err_string_n
6d69dc5 Degrade 3DES to MEDIUM in SSL2
e8e380c RT is put out to pasture
f1f9769 Add missing error string for SSL_R_TOO_MANY_WARN_ALERTS
53a71b7 apps/apps.c: initialize and de-initialize engine
around key loading
a269e5f Revert "Call ENGINE_init() before trying to use keys
from engine"
4badd2b Call ENGINE_init() before trying to use keys from engine
9702bf5 Fix NEWS error
f6e43fe Prepare for 1.0.2k-dev


I've look at any commits that *seem* like they could be more than
a bug fix or that might change the api. Aside from the two issues
related to header files, I didn't see anything to worry about.

$ git diff OpenSSL_1_0_2j..OpenSSL_1_0_2k | diffstat
.travis.yml | 2
CHANGES | 61 ++++++
CONTRIBUTING | 55 +----
Configure | 34 ++-
INSTALL | 69 +++---
Makefile.org | 3
NEWS | 8
README | 36 ---
apps/apps.c | 19 +
apps/apps.h | 4
apps/ca.c | 6
apps/cms.c | 5
apps/dgst.c | 1
apps/dh.c | 6
apps/dhparam.c | 8
apps/dsa.c | 7
apps/dsaparam.c | 8
apps/ec.c | 6
apps/ecparam.c | 10
apps/enc.c | 8
apps/gendh.c | 4
apps/gendsa.c | 8
apps/genpkey.c | 2
apps/genrsa.c | 7
apps/pkcs12.c | 7
apps/pkcs7.c | 8
apps/pkcs8.c | 5
apps/pkey.c | 5
apps/pkeyparam.c | 8
apps/pkeyutl.c | 1
apps/prime.c | 12 -
apps/rand.c | 8
apps/req.c | 5
apps/rsa.c | 5
apps/rsautl.c | 5
apps/s_cb.c | 4
apps/s_client.c | 7
apps/s_server.c | 7
apps/smime.c | 5
apps/speed.c | 14 -
apps/spkac.c | 5
apps/srp.c | 8
apps/verify.c | 5
apps/x509.c | 5
crypto/aes/asm/aes-s390x.pl | 8
crypto/asn1/p5_pbev2.c | 8
crypto/asn1/x_crl.c | 3
crypto/bn/asm/x86_64-mont.pl | 5
crypto/bn/asm/x86_64-mont5.pl | 16 -
crypto/bn/bn_exp.c | 5
crypto/bn/bn_mul.c | 5
crypto/bn/bn_prime.c | 3
crypto/bn/bn_sqr.c | 5
crypto/cms/cms_kari.c | 5
crypto/dh/dh_key.c | 2
crypto/dsa/dsa_pmeth.c | 2
crypto/ec/ec2_mult.c | 20 +
crypto/ecdh/ech_ossl.c | 4
crypto/err/err.c | 3
crypto/evp/e_aes.c | 4
crypto/evp/e_rc4_hmac_md5.c | 2
crypto/evp/evp.h | 6
crypto/evp/evp_err.c | 3
crypto/evp/pmeth_fn.c | 30 +-
crypto/evp/pmeth_lib.c | 28 --
crypto/modes/ctr128.c | 2
crypto/opensslv.h | 6
crypto/perlasm/x86_64-xlate.pl | 11 -
crypto/rsa/rsa_gen.c | 3
crypto/rsa/rsa_oaep.c | 8
crypto/rsa/rsa_pmeth.c | 4
crypto/s390xcap.c | 1
crypto/ui/ui_lib.c | 138 +++++++------
crypto/ui/ui_openssl.c | 59 +++--
demos/easy_tls/easy-tls.c | 1
doc/apps/ocsp.pod | 9
doc/crypto/EVP_DigestSignInit.pod | 2
doc/crypto/EVP_DigestVerifyInit.pod | 2
doc/crypto/RSA_generate_key.pod | 2
doc/crypto/X509_NAME_get_index_by_NID.pod | 3
doc/crypto/X509_NAME_print_ex.pod | 8
doc/ssl/SSL_CTX_set_session_cache_mode.pod | 2
doc/ssl/SSL_get_error.pod | 22 --
doc/ssl/SSL_read.pod | 32 +--
doc/ssl/SSL_write.pod | 19 -
engines/ccgost/Makefile | 2
openssl.spec | 2
ssl/bad_dtls_test.c | 5
ssl/s23_pkt.c | 12 -
ssl/s2_lib.c | 2
ssl/s2_pkt.c | 10
ssl/s3_clnt.c | 44 +++-
ssl/s3_pkt.c | 23 +-
ssl/s3_srvr.c | 33 ++-
ssl/ssl_cert.c | 4
ssl/ssl_err.c | 1
ssl/ssl_lib.c | 4
ssl/ssl_locl.h | 2
ssl/ssl_sess.c | 9
ssl/t1_lib.c | 291
++++++++++++++++++-----------
util/domd | 11 -
util/mklink.pl | 8
102 files changed, 836 insertions(+), 634 deletions(-)



_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5


Re: Yocto post-release CVE and package uprev policy - openssl, ffmpeg, etc.

Randy MacLeod
 

On 2017-01-27 07:31 AM, Alexander Kanavin wrote:
On 01/26/2017 10:10 PM, Randy MacLeod wrote:
I've done a review of openssl below but
before I proceed with more evaluation or sending the
uprev to the list for morty, I'd like to know if the upgrade
policy will block such a change. From my analysis, there's only
one change that seems like an upgrade blocker and I need help
to evaluate that since I'm not an openssl maintainer.

The change to always call setup_engine() may be a problem
but I'm not familiar with the openssl code base so I'm
not sure how big a deal it is. Alex, are you familiar with
this part of openssl?
Randy, you are starting with a wrong assumption: that people listed in
maintainers.inc are real maintainers - real in the sense that they
follow upstream development, take care of regular runtime testing
(including writing the testsuite if upstream doesn't provide a good
one), and understand the source code well to make informed decisions.
That is simply not true. I have no idea about what goes on inside
openssl, and I think no one else in Yocto does. My duty is updating
openssl to the latest version in master and reacting to bug reports;
there's simply no time for more.
Well, I expected such a reply but hoped to be surprised. It's a
tough call as a distro maintainer. I wonder if maintainers for other
major distros would generally have the same concerns about lack of time
to develop the required expertise or is Yocto different due to lack of
community participation.

We need to spread out recipe maintainership a lot more than is the case
currently, then we can have a sane policy in place for stable releases.

Alex
That makes sense to me as well.


--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5


Re: Yocto post-release CVE and package uprev policy - openssl, ffmpeg, etc.

Khem Raj
 

On 1/30/17 9:31 AM, Mark Hatle wrote:
On 1/30/17 10:45 AM, akuster808 wrote:


On 01/26/2017 12:10 PM, Randy MacLeod wrote:

Yocto seems to have a policy not to update packages once a
release is generally available.
I believe this is already covered in the current policy.

(lifted from policy)
No recipe upgrades unless:
The new version contains a security patch or other critical bugfix that
is too difficult to backport to the version already in the stable branch.

does that not cover this concern?
No. The issue is that there are other non-security fixes that are roughly being
ignored. And we often get a lot of the "why aren't you on version XYZ of
OpenSSL" type questions.

Doesn't matter if it's up-to-date or not, they're convinced by their 'security
scanning software' that anything it says 'might' have a problem -does- have a
problem.
I am aware of such tools which do version matching and slap a list of
CVEs at you without knowing anything else about the software. It would
be more useful if these software really looked at a given CVE and
detected that provided fix has been applied. I am not sure if this
should be a motivation for changing the policy. Moreover it does not end
with openssl, there is libcurl, libpng, freetype you name it, its an
endless list. So we could contemplate a move to rolling release model
or we could define a semi-rolling release model which definitely
involves more testing effort in point releases.


As others have indicate the worry is always around the APIs. They change and it
screws up everything else.

(there is also a secondary issue of... it's easier to just jump versions, then
backport fixes and verify the fixes are working...)
It might be easier build time, I dont think it changes runtime test matrix

it will be interesting to know what do other distros which do time based
releases as well do in such regard. e.g. centos, debian.


--Mark


I think that rule should be
broken for certain packages that have been reviewed and tested
properly.
To me the responsibility is on the person who wants for issue fixed via
a package update. They need to convince the package maintainer or branch
maintainer that this is the better course of action than to back port a
patch.

See:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10707
for additional background.

For some packages, the upstream development team fixes CVE and
other bugs on their released version and by YP only cherry-picking back
specific fixes, we expose users to additional risk and incur higher
costs of maintenance. At least two packages that I know of have released
"bug fix only" updates to fix CVEs and other defects for packages
that are in morty:

- openssl 1.0.2j -> 1.0.2k
- ffmpeg 3.1.3 -> 3.1.5
Gcc, Glibc and kernel fall into this bucket too so where do you draw the
line?

Should we continue to cherry-pick back only the CVEs fixes
or should we review, test, and release the full minor release?
My preference is to improve the guidelines rather than creating
exceptions. There is the scenario that if a CVE fix exists and no new
package version has been released, we should wait.

It not uncommon for a commit message to a package upgrade lacks
information to help a stable branch maintainer make a decision for
backporting.


I've done a review of openssl below but
before I proceed with more evaluation or sending the
uprev to the list for morty, I'd like to know if the upgrade
policy will block such a change. From my analysis, there's only
one change that seems like an upgrade blocker and I need help
to evaluate that since I'm not an openssl maintainer.


I've done the upgrade locally. It's just a few lines and builds
seem to be fine so far. I'll send the upgrade for master
at least once my builds complete and I've done some other
tests.
Then send patches and explain why. The maintainer of the stable branch
appears to be some what reasonable and does appreciate all input on what
should be back ported to the stable branches.

Regards,
Armin


../Randy


Review of openssl-1.0.2j->k.


Early next week, I'll check for an update on: 1.0.2j->k compatibility
here:
https://abi-laboratory.pro/tracker/timeline/openssl/
'k' hasn't been done as of Jan 26th.


I looked at the 78 changes to openssl-1.0.2j->k and
found that 4 header files had changed. Here's a list of
the header files and my conclusion/summary.

$ git diff OpenSSL_1_0_2j..OpenSSL_1_0_2k | \
diffstat| grep "\.h"
apps/apps.h | 4
--> Add: always call setup_engine
crypto/evp/evp.h | 6
--> +# define EVP_R_INVALID_KEY and whitespace
crypto/opensslv.h | 6
--> version update
ssl/ssl_locl.h | 2
--> api change but according to [1] it's an internal header
-int ssl_check_clienthello_tlsext_late(SSL *s);
+int ssl_check_clienthello_tlsext_late(SSL *s, int *al);


[1] Mr Burton claims this is (or was?) a private api:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641711


The change to always call setup_engine() may be a problem
but I'm not familiar with the openssl code base so I'm
not sure how big a deal it is. Alex, are you familiar with
this part of openssl?


Here is a list of the commits:

$ git log --oneline OpenSSL_1_0_2j..OpenSSL_1_0_2k | wc -l
78

$ git log --oneline OpenSSL_1_0_2j..OpenSSL_1_0_2k

081314d Prepare for 1.0.2k release
06f87e9 Update CHANGES and NEWS for new release
918d8ea Better check of DH parameters in TLS data
760d043 bn/asm/x86_64-mont5.pl: fix carry bug in bn_sqr8x_internal.
51d0090 crypto/evp: harden RC4_MD5 cipher.
8957add Fix error handling in compute_key, BN_CTX_get can return NULL
cb00d4f Fix a ssl session leak due to OOM in lh_SSL_SESSION_insert
e203f49 Fix SSL_VERIFY_CLIENT_ONCE
149e98d Add missing va_end
16f013f Fix DSA parameter generation control error
52b703f Clean one unused variable, plus an useless one.
1f234f7 GH1986: Document -header flag.
0ecb682 Fix error handling in SSL_CTX_new
2045c58 Fix a memory leak in RSA_padding_add_PKCS1_OAEP_mgf1
18b8431 replace "will lookup up" by "will look up"
58c81e7 Reformat M_check_autoarg to match our coding style
222333c M_check_autoarg: sanity check the key
3fb9f87 Fix typo.
5bbedd3 zero pad DHE public key in ServerKeyExchange message for interop
70705b2 Fix ssl_cert_dup: change one 'return NULL' to 'goto err'
3b584ef Make 'err' lable in ssl_cert_dup unconditional
292bb56 Fix a bug in clienthello processing
7624a31 perlasm/x86_64-xlate.pl: refine sign extension in ea package.
10a5037 UI_OpenSSL()'s session opener fails on MacOS X
78a3e80 VMS UI_OpenSSL:
if the TT device isn't a tty, flag instead of error
fecd4c2 Check input length to pkey_rsa_verify()
5ae285e Remove extra bang
59ba83c UI code style cleanup
748a2d9 Revert "Fix heartbeat_test"
be3a7dd apps/speed.c: Fix crash when config loading fails
c477f8e INSTALL: clarify 386 and no-sse2 options.
f47201b modes/ctr128.c: fix false carry in counter increment procedure.
c4c7165 Clarify what X509_NAME_online does with
the given buffer and size
31b4307 Make SSL_read and SSL_write return
the old behaviour and document it.
09b894b Use consistent variable names
f4ef1c5 domd: Preserve Makefile time when it is unchanged
7a9d712 mklink: Do not needlessly overwrite linked files...
62f16de domd: Do not needlessly overwrite Makefiles
22cc44d mklink: Do not needlessly overwrite linked files...
ecc9551 Configure: Improve incremental build time
8ac70be Check return value of some BN functions.
3201a1d Solution proposal for issue #1647.
19e1de5 Update CHANGES and NEWS
57c4b9f bn/asm/x86_64-mont.pl: fix for CVE-2016-7055 (Low severity).
c210840 Makefile.org: clear APPS environment variable.
95873c5 Missed a mention of RT
563a34e Add a CHANGES entry for the unrecognised record type change
f118539 Fail if an unrecognised record type is received
ad69a30 Fix heartbeat_test
ba2bf83 Secure our notification email.
e022375 Fix grammar-o in CONTRIBUTING
787b2dc Add $(EX_LIBS) to the LIBDEPS for libgost.so,
just as for all other engines
0b9c5da Implement length checks as a macro
a520723 Ensure we have length checks for all extensions
83a1d4b Fix length check writing status request extension
57aa2f1 Fix a double free in ca command line
fa4c374 A zero return from BIO_read/BIO_write() could be retryable
31bf65c Fix typo (reported by Matthias St. Pierre)
0e46901 Fix leak of secrecy in ecdh_compute_key()
3ade92e Correctly find all critical CRL extensions
45f4761 remove redundant zero assignments
cdb203f %p takes void*, so make sure to cast arguments to void*
0df1caa apps: make setup_engine() and release_engine() available always
aa01b82 If an engine comes up explicitely,
it must also come down explicitely
10e60f2 Fix no-des
1c6aab6 Make 'openssl prime ""' not segfault
99c002b Fix strict-warnings build
b0161f6 Fix strict-warnings build
78ee64c Fix signatures of EVP_Digest{Sign,Verify}Update
02a0231 Ensure we handle len == 0 in ERR_err_string_n
6d69dc5 Degrade 3DES to MEDIUM in SSL2
e8e380c RT is put out to pasture
f1f9769 Add missing error string for SSL_R_TOO_MANY_WARN_ALERTS
53a71b7 apps/apps.c: initialize and de-initialize engine
around key loading
a269e5f Revert "Call ENGINE_init() before trying to use keys
from engine"
4badd2b Call ENGINE_init() before trying to use keys from engine
9702bf5 Fix NEWS error
f6e43fe Prepare for 1.0.2k-dev


I've look at any commits that *seem* like they could be more than
a bug fix or that might change the api. Aside from the two issues
related to header files, I didn't see anything to worry about.

$ git diff OpenSSL_1_0_2j..OpenSSL_1_0_2k | diffstat
.travis.yml | 2
CHANGES | 61 ++++++
CONTRIBUTING | 55 +----
Configure | 34 ++-
INSTALL | 69 +++---
Makefile.org | 3
NEWS | 8
README | 36 ---
apps/apps.c | 19 +
apps/apps.h | 4
apps/ca.c | 6
apps/cms.c | 5
apps/dgst.c | 1
apps/dh.c | 6
apps/dhparam.c | 8
apps/dsa.c | 7
apps/dsaparam.c | 8
apps/ec.c | 6
apps/ecparam.c | 10
apps/enc.c | 8
apps/gendh.c | 4
apps/gendsa.c | 8
apps/genpkey.c | 2
apps/genrsa.c | 7
apps/pkcs12.c | 7
apps/pkcs7.c | 8
apps/pkcs8.c | 5
apps/pkey.c | 5
apps/pkeyparam.c | 8
apps/pkeyutl.c | 1
apps/prime.c | 12 -
apps/rand.c | 8
apps/req.c | 5
apps/rsa.c | 5
apps/rsautl.c | 5
apps/s_cb.c | 4
apps/s_client.c | 7
apps/s_server.c | 7
apps/smime.c | 5
apps/speed.c | 14 -
apps/spkac.c | 5
apps/srp.c | 8
apps/verify.c | 5
apps/x509.c | 5
crypto/aes/asm/aes-s390x.pl | 8
crypto/asn1/p5_pbev2.c | 8
crypto/asn1/x_crl.c | 3
crypto/bn/asm/x86_64-mont.pl | 5
crypto/bn/asm/x86_64-mont5.pl | 16 -
crypto/bn/bn_exp.c | 5
crypto/bn/bn_mul.c | 5
crypto/bn/bn_prime.c | 3
crypto/bn/bn_sqr.c | 5
crypto/cms/cms_kari.c | 5
crypto/dh/dh_key.c | 2
crypto/dsa/dsa_pmeth.c | 2
crypto/ec/ec2_mult.c | 20 +
crypto/ecdh/ech_ossl.c | 4
crypto/err/err.c | 3
crypto/evp/e_aes.c | 4
crypto/evp/e_rc4_hmac_md5.c | 2
crypto/evp/evp.h | 6
crypto/evp/evp_err.c | 3
crypto/evp/pmeth_fn.c | 30 +-
crypto/evp/pmeth_lib.c | 28 --
crypto/modes/ctr128.c | 2
crypto/opensslv.h | 6
crypto/perlasm/x86_64-xlate.pl | 11 -
crypto/rsa/rsa_gen.c | 3
crypto/rsa/rsa_oaep.c | 8
crypto/rsa/rsa_pmeth.c | 4
crypto/s390xcap.c | 1
crypto/ui/ui_lib.c | 138 +++++++------
crypto/ui/ui_openssl.c | 59 +++--
demos/easy_tls/easy-tls.c | 1
doc/apps/ocsp.pod | 9
doc/crypto/EVP_DigestSignInit.pod | 2
doc/crypto/EVP_DigestVerifyInit.pod | 2
doc/crypto/RSA_generate_key.pod | 2
doc/crypto/X509_NAME_get_index_by_NID.pod | 3
doc/crypto/X509_NAME_print_ex.pod | 8
doc/ssl/SSL_CTX_set_session_cache_mode.pod | 2
doc/ssl/SSL_get_error.pod | 22 --
doc/ssl/SSL_read.pod | 32 +--
doc/ssl/SSL_write.pod | 19 -
engines/ccgost/Makefile | 2
openssl.spec | 2
ssl/bad_dtls_test.c | 5
ssl/s23_pkt.c | 12 -
ssl/s2_lib.c | 2
ssl/s2_pkt.c | 10
ssl/s3_clnt.c | 44 +++-
ssl/s3_pkt.c | 23 +-
ssl/s3_srvr.c | 33 ++-
ssl/ssl_cert.c | 4
ssl/ssl_err.c | 1
ssl/ssl_lib.c | 4
ssl/ssl_locl.h | 2
ssl/ssl_sess.c | 9
ssl/t1_lib.c | 291
++++++++++++++++++-----------
util/domd | 11 -
util/mklink.pl | 8
102 files changed, 836 insertions(+), 634 deletions(-)



_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


Re: Yocto post-release CVE and package uprev policy - openssl, ffmpeg, etc.

Mark Hatle <mark.hatle@...>
 

On 1/30/17 10:45 AM, akuster808 wrote:


On 01/26/2017 12:10 PM, Randy MacLeod wrote:

Yocto seems to have a policy not to update packages once a
release is generally available.
I believe this is already covered in the current policy.

(lifted from policy)
No recipe upgrades unless:
The new version contains a security patch or other critical bugfix that
is too difficult to backport to the version already in the stable branch.

does that not cover this concern?
No. The issue is that there are other non-security fixes that are roughly being
ignored. And we often get a lot of the "why aren't you on version XYZ of
OpenSSL" type questions.

Doesn't matter if it's up-to-date or not, they're convinced by their 'security
scanning software' that anything it says 'might' have a problem -does- have a
problem.

As others have indicate the worry is always around the APIs. They change and it
screws up everything else.

(there is also a secondary issue of... it's easier to just jump versions, then
backport fixes and verify the fixes are working...)

--Mark


I think that rule should be
broken for certain packages that have been reviewed and tested
properly.
To me the responsibility is on the person who wants for issue fixed via
a package update. They need to convince the package maintainer or branch
maintainer that this is the better course of action than to back port a
patch.

See:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10707
for additional background.

For some packages, the upstream development team fixes CVE and
other bugs on their released version and by YP only cherry-picking back
specific fixes, we expose users to additional risk and incur higher
costs of maintenance. At least two packages that I know of have released
"bug fix only" updates to fix CVEs and other defects for packages
that are in morty:

- openssl 1.0.2j -> 1.0.2k
- ffmpeg 3.1.3 -> 3.1.5
Gcc, Glibc and kernel fall into this bucket too so where do you draw the
line?

Should we continue to cherry-pick back only the CVEs fixes
or should we review, test, and release the full minor release?
My preference is to improve the guidelines rather than creating
exceptions. There is the scenario that if a CVE fix exists and no new
package version has been released, we should wait.

It not uncommon for a commit message to a package upgrade lacks
information to help a stable branch maintainer make a decision for
backporting.


I've done a review of openssl below but
before I proceed with more evaluation or sending the
uprev to the list for morty, I'd like to know if the upgrade
policy will block such a change. From my analysis, there's only
one change that seems like an upgrade blocker and I need help
to evaluate that since I'm not an openssl maintainer.


I've done the upgrade locally. It's just a few lines and builds
seem to be fine so far. I'll send the upgrade for master
at least once my builds complete and I've done some other
tests.
Then send patches and explain why. The maintainer of the stable branch
appears to be some what reasonable and does appreciate all input on what
should be back ported to the stable branches.

Regards,
Armin


../Randy


Review of openssl-1.0.2j->k.


Early next week, I'll check for an update on: 1.0.2j->k compatibility
here:
https://abi-laboratory.pro/tracker/timeline/openssl/
'k' hasn't been done as of Jan 26th.


I looked at the 78 changes to openssl-1.0.2j->k and
found that 4 header files had changed. Here's a list of
the header files and my conclusion/summary.

$ git diff OpenSSL_1_0_2j..OpenSSL_1_0_2k | \
diffstat| grep "\.h"
apps/apps.h | 4
--> Add: always call setup_engine
crypto/evp/evp.h | 6
--> +# define EVP_R_INVALID_KEY and whitespace
crypto/opensslv.h | 6
--> version update
ssl/ssl_locl.h | 2
--> api change but according to [1] it's an internal header
-int ssl_check_clienthello_tlsext_late(SSL *s);
+int ssl_check_clienthello_tlsext_late(SSL *s, int *al);


[1] Mr Burton claims this is (or was?) a private api:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641711


The change to always call setup_engine() may be a problem
but I'm not familiar with the openssl code base so I'm
not sure how big a deal it is. Alex, are you familiar with
this part of openssl?


Here is a list of the commits:

$ git log --oneline OpenSSL_1_0_2j..OpenSSL_1_0_2k | wc -l
78

$ git log --oneline OpenSSL_1_0_2j..OpenSSL_1_0_2k

081314d Prepare for 1.0.2k release
06f87e9 Update CHANGES and NEWS for new release
918d8ea Better check of DH parameters in TLS data
760d043 bn/asm/x86_64-mont5.pl: fix carry bug in bn_sqr8x_internal.
51d0090 crypto/evp: harden RC4_MD5 cipher.
8957add Fix error handling in compute_key, BN_CTX_get can return NULL
cb00d4f Fix a ssl session leak due to OOM in lh_SSL_SESSION_insert
e203f49 Fix SSL_VERIFY_CLIENT_ONCE
149e98d Add missing va_end
16f013f Fix DSA parameter generation control error
52b703f Clean one unused variable, plus an useless one.
1f234f7 GH1986: Document -header flag.
0ecb682 Fix error handling in SSL_CTX_new
2045c58 Fix a memory leak in RSA_padding_add_PKCS1_OAEP_mgf1
18b8431 replace "will lookup up" by "will look up"
58c81e7 Reformat M_check_autoarg to match our coding style
222333c M_check_autoarg: sanity check the key
3fb9f87 Fix typo.
5bbedd3 zero pad DHE public key in ServerKeyExchange message for interop
70705b2 Fix ssl_cert_dup: change one 'return NULL' to 'goto err'
3b584ef Make 'err' lable in ssl_cert_dup unconditional
292bb56 Fix a bug in clienthello processing
7624a31 perlasm/x86_64-xlate.pl: refine sign extension in ea package.
10a5037 UI_OpenSSL()'s session opener fails on MacOS X
78a3e80 VMS UI_OpenSSL:
if the TT device isn't a tty, flag instead of error
fecd4c2 Check input length to pkey_rsa_verify()
5ae285e Remove extra bang
59ba83c UI code style cleanup
748a2d9 Revert "Fix heartbeat_test"
be3a7dd apps/speed.c: Fix crash when config loading fails
c477f8e INSTALL: clarify 386 and no-sse2 options.
f47201b modes/ctr128.c: fix false carry in counter increment procedure.
c4c7165 Clarify what X509_NAME_online does with
the given buffer and size
31b4307 Make SSL_read and SSL_write return
the old behaviour and document it.
09b894b Use consistent variable names
f4ef1c5 domd: Preserve Makefile time when it is unchanged
7a9d712 mklink: Do not needlessly overwrite linked files...
62f16de domd: Do not needlessly overwrite Makefiles
22cc44d mklink: Do not needlessly overwrite linked files...
ecc9551 Configure: Improve incremental build time
8ac70be Check return value of some BN functions.
3201a1d Solution proposal for issue #1647.
19e1de5 Update CHANGES and NEWS
57c4b9f bn/asm/x86_64-mont.pl: fix for CVE-2016-7055 (Low severity).
c210840 Makefile.org: clear APPS environment variable.
95873c5 Missed a mention of RT
563a34e Add a CHANGES entry for the unrecognised record type change
f118539 Fail if an unrecognised record type is received
ad69a30 Fix heartbeat_test
ba2bf83 Secure our notification email.
e022375 Fix grammar-o in CONTRIBUTING
787b2dc Add $(EX_LIBS) to the LIBDEPS for libgost.so,
just as for all other engines
0b9c5da Implement length checks as a macro
a520723 Ensure we have length checks for all extensions
83a1d4b Fix length check writing status request extension
57aa2f1 Fix a double free in ca command line
fa4c374 A zero return from BIO_read/BIO_write() could be retryable
31bf65c Fix typo (reported by Matthias St. Pierre)
0e46901 Fix leak of secrecy in ecdh_compute_key()
3ade92e Correctly find all critical CRL extensions
45f4761 remove redundant zero assignments
cdb203f %p takes void*, so make sure to cast arguments to void*
0df1caa apps: make setup_engine() and release_engine() available always
aa01b82 If an engine comes up explicitely,
it must also come down explicitely
10e60f2 Fix no-des
1c6aab6 Make 'openssl prime ""' not segfault
99c002b Fix strict-warnings build
b0161f6 Fix strict-warnings build
78ee64c Fix signatures of EVP_Digest{Sign,Verify}Update
02a0231 Ensure we handle len == 0 in ERR_err_string_n
6d69dc5 Degrade 3DES to MEDIUM in SSL2
e8e380c RT is put out to pasture
f1f9769 Add missing error string for SSL_R_TOO_MANY_WARN_ALERTS
53a71b7 apps/apps.c: initialize and de-initialize engine
around key loading
a269e5f Revert "Call ENGINE_init() before trying to use keys
from engine"
4badd2b Call ENGINE_init() before trying to use keys from engine
9702bf5 Fix NEWS error
f6e43fe Prepare for 1.0.2k-dev


I've look at any commits that *seem* like they could be more than
a bug fix or that might change the api. Aside from the two issues
related to header files, I didn't see anything to worry about.

$ git diff OpenSSL_1_0_2j..OpenSSL_1_0_2k | diffstat
.travis.yml | 2
CHANGES | 61 ++++++
CONTRIBUTING | 55 +----
Configure | 34 ++-
INSTALL | 69 +++---
Makefile.org | 3
NEWS | 8
README | 36 ---
apps/apps.c | 19 +
apps/apps.h | 4
apps/ca.c | 6
apps/cms.c | 5
apps/dgst.c | 1
apps/dh.c | 6
apps/dhparam.c | 8
apps/dsa.c | 7
apps/dsaparam.c | 8
apps/ec.c | 6
apps/ecparam.c | 10
apps/enc.c | 8
apps/gendh.c | 4
apps/gendsa.c | 8
apps/genpkey.c | 2
apps/genrsa.c | 7
apps/pkcs12.c | 7
apps/pkcs7.c | 8
apps/pkcs8.c | 5
apps/pkey.c | 5
apps/pkeyparam.c | 8
apps/pkeyutl.c | 1
apps/prime.c | 12 -
apps/rand.c | 8
apps/req.c | 5
apps/rsa.c | 5
apps/rsautl.c | 5
apps/s_cb.c | 4
apps/s_client.c | 7
apps/s_server.c | 7
apps/smime.c | 5
apps/speed.c | 14 -
apps/spkac.c | 5
apps/srp.c | 8
apps/verify.c | 5
apps/x509.c | 5
crypto/aes/asm/aes-s390x.pl | 8
crypto/asn1/p5_pbev2.c | 8
crypto/asn1/x_crl.c | 3
crypto/bn/asm/x86_64-mont.pl | 5
crypto/bn/asm/x86_64-mont5.pl | 16 -
crypto/bn/bn_exp.c | 5
crypto/bn/bn_mul.c | 5
crypto/bn/bn_prime.c | 3
crypto/bn/bn_sqr.c | 5
crypto/cms/cms_kari.c | 5
crypto/dh/dh_key.c | 2
crypto/dsa/dsa_pmeth.c | 2
crypto/ec/ec2_mult.c | 20 +
crypto/ecdh/ech_ossl.c | 4
crypto/err/err.c | 3
crypto/evp/e_aes.c | 4
crypto/evp/e_rc4_hmac_md5.c | 2
crypto/evp/evp.h | 6
crypto/evp/evp_err.c | 3
crypto/evp/pmeth_fn.c | 30 +-
crypto/evp/pmeth_lib.c | 28 --
crypto/modes/ctr128.c | 2
crypto/opensslv.h | 6
crypto/perlasm/x86_64-xlate.pl | 11 -
crypto/rsa/rsa_gen.c | 3
crypto/rsa/rsa_oaep.c | 8
crypto/rsa/rsa_pmeth.c | 4
crypto/s390xcap.c | 1
crypto/ui/ui_lib.c | 138 +++++++------
crypto/ui/ui_openssl.c | 59 +++--
demos/easy_tls/easy-tls.c | 1
doc/apps/ocsp.pod | 9
doc/crypto/EVP_DigestSignInit.pod | 2
doc/crypto/EVP_DigestVerifyInit.pod | 2
doc/crypto/RSA_generate_key.pod | 2
doc/crypto/X509_NAME_get_index_by_NID.pod | 3
doc/crypto/X509_NAME_print_ex.pod | 8
doc/ssl/SSL_CTX_set_session_cache_mode.pod | 2
doc/ssl/SSL_get_error.pod | 22 --
doc/ssl/SSL_read.pod | 32 +--
doc/ssl/SSL_write.pod | 19 -
engines/ccgost/Makefile | 2
openssl.spec | 2
ssl/bad_dtls_test.c | 5
ssl/s23_pkt.c | 12 -
ssl/s2_lib.c | 2
ssl/s2_pkt.c | 10
ssl/s3_clnt.c | 44 +++-
ssl/s3_pkt.c | 23 +-
ssl/s3_srvr.c | 33 ++-
ssl/ssl_cert.c | 4
ssl/ssl_err.c | 1
ssl/ssl_lib.c | 4
ssl/ssl_locl.h | 2
ssl/ssl_sess.c | 9
ssl/t1_lib.c | 291
++++++++++++++++++-----------
util/domd | 11 -
util/mklink.pl | 8
102 files changed, 836 insertions(+), 634 deletions(-)



_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

1261 - 1280 of 1685