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


Randy MacLeod
 

Yocto seems to have a policy not to update packages once a
release is generally available. I think that rule should be
broken for certain packages that have been reviewed and tested
properly.

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

Should we continue to cherry-pick back only the CVEs fixes
or should we review, test, and release the full minor release?


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.

../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(-)




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


Khem Raj
 

On 1/26/17 12:10 PM, Randy MacLeod wrote:

Yocto seems to have a policy not to update packages once a
release is generally available. I think that rule should be
broken for certain packages that have been reviewed and tested
properly.

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

Should we continue to cherry-pick back only the CVEs fixes
or should we review, test, and release the full minor release?
If upstream claims j->k release to just have CVE changesets may be its
not a problem, however if there are more fixes that comes along with
CVEs then we need to understand closely what these fixes are what do
they break, IMO, this could be ok if we have some sort of API/ABI
testing to ensure that nothing else breaks, otherwise someone should sit
and bean the commits for what they are changing.


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.

../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(-)




Paul Eggleton <paul.eggleton@...>
 

On Thursday, 26 January 2017 3:10:57 PM NZDT Randy MacLeod wrote:
Yocto seems to have a policy not to update packages once a
release is generally available. I think that rule should be
broken for certain packages that have been reviewed and tested
properly.
We have made exceptions in the past for exactly the reasons you outline.
Unfortunately I know at least for OpenSSL when we have done so on at least one
occasion we have been bitten by compatibility issues :(

If we can introduce more rigorous runtime testing (and by that I don't just
mean tests for the package itself - runtime tests for functionality in other
applications that rely on that package would be preferred) then we would be in
a much better place. Being able to measure ABI compatibility is a good start
but doesn't cover any internal changes in behaviour that might be problematic.

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

Should we continue to cherry-pick back only the CVEs fixes
or should we review, test, and release the full minor release?


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 would say we're not hard-blocked by the policy - we can make exceptions, but
we really do need to be careful, and I don't think we're prepared to make a
continuing exception for specific packages yet. The better idea we can get
that there won't be regressions, hopefully in an automated or semi-automated
manner, the safer position we'll be in.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Alexander Kanavin <alexander.kanavin@...>
 

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.

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


Khem Raj
 

On 1/26/17 8:04 PM, Paul Eggleton wrote:
On Thursday, 26 January 2017 3:10:57 PM NZDT Randy MacLeod wrote:
Yocto seems to have a policy not to update packages once a
release is generally available. I think that rule should be
broken for certain packages that have been reviewed and tested
properly.
We have made exceptions in the past for exactly the reasons you outline.
Unfortunately I know at least for OpenSSL when we have done so on at least one
occasion we have been bitten by compatibility issues :(

If we can introduce more rigorous runtime testing (and by that I don't just
mean tests for the package itself - runtime tests for functionality in other
applications that rely on that package would be preferred) then we would be in
a much better place. Being able to measure ABI compatibility is a good start
but doesn't cover any internal changes in behaviour that might be problematic.

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

Should we continue to cherry-pick back only the CVEs fixes
or should we review, test, and release the full minor release?


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 think we can contexualize it based upon amount of work, openssl has
violated ABI within same major release in past see 1.0.2f -> 1.0.2g

For complete list

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

We may use that as guiding light to make a decision for backporting CVEs
or do a minor upgrade.


I would say we're not hard-blocked by the policy - we can make exceptions, but
we really do need to be careful, and I don't think we're prepared to make a
continuing exception for specific packages yet. The better idea we can get
that there won't be regressions, hopefully in an automated or semi-automated
manner, the safer position we'll be in.

Cheers,
Paul


Martin Jansa
 

On Fri, Jan 27, 2017 at 09:43:42AM -0800, Khem Raj wrote:


On 1/26/17 8:04 PM, Paul Eggleton wrote:
On Thursday, 26 January 2017 3:10:57 PM NZDT Randy MacLeod wrote:
Yocto seems to have a policy not to update packages once a
release is generally available. I think that rule should be
broken for certain packages that have been reviewed and tested
properly.
We have made exceptions in the past for exactly the reasons you outline.
Unfortunately I know at least for OpenSSL when we have done so on at least one
occasion we have been bitten by compatibility issues :(

If we can introduce more rigorous runtime testing (and by that I don't just
mean tests for the package itself - runtime tests for functionality in other
applications that rely on that package would be preferred) then we would be in
a much better place. Being able to measure ABI compatibility is a good start
but doesn't cover any internal changes in behaviour that might be problematic.

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

Should we continue to cherry-pick back only the CVEs fixes
or should we review, test, and release the full minor release?


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 think we can contexualize it based upon amount of work, openssl has
violated ABI within same major release in past see 1.0.2f -> 1.0.2g

For complete list

https://abi-laboratory.pro/tracker/timeline/openssl/
And when the upstream didn't break the ABI, we did with seemingly safe
change of version-script.patch:

http://git.openembedded.org/openembedded-core/commit/?h=jethro&id=528541845df34843c14be5de62e9f53004d292ac
http://git.openembedded.org/openembedded-core/commit/?h=krogoth&id=08f85da10b3a7fc6165f163fd0f23784a2c9c8e4

So I agree that we should be very careful and make as few exceptions as
possible at least until there is strong testing for API/ABI
compatibility for release branches.

We may use that as guiding light to make a decision for backporting CVEs
or do a minor upgrade.


I would say we're not hard-blocked by the policy - we can make exceptions, but
we really do need to be careful, and I don't think we're prepared to make a
continuing exception for specific packages yet. The better idea we can get
that there won't be regressions, hopefully in an automated or semi-automated
manner, the safer position we'll be in.

Cheers,
Paul
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@...


Armin Kuster
 

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?

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(-)




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


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


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


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


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


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