[Openembedded-architecture] Yocto post-release CVE and package uprev policy - openssl, ffmpeg, etc.
Randy MacLeod
randy.macleod at windriver.com
Mon Jan 30 22:09:15 UTC 2017
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 at lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>>>
>>
>> _______________________________________________
>> Openembedded-architecture mailing list
>> Openembedded-architecture at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>>
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> 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
More information about the Openembedded-architecture
mailing list