Description: "Arm Mbed TLS before 2.6.15 allows attackers to obtain sensitive information (an RSA private key) by measuring cache usage during an import." Note that from the advisory (URL), the affected upstream versions are as follows: - <2.7.14 (2.7.x not in tree) - <2.16.5 (2.16.x not in tree) - <2.21.0
(In reply to sam_c (Security Padawan) from comment #0) > Note that from the advisory (URL), the affected upstream versions are as > follows: > - <2.7.14 (2.7.x not in tree) > - <2.16.5 (2.16.x not in tree) > - <2.21.0 @maintainer(s), please create an appropriate ebuild.
> > - <2.7.14 (2.7.x not in tree) Correct, this is not in the tree. > > - <2.16.5 (2.16.x not in tree) 2.16.6 *is* in the tree and stable. > > - <2.21.0 I just added 2.22.0. We do have 2.19.1-r2 stable and it should be removed in favor of 2.22.0, so let's begin a rapid stabilization on it. @arch teams, the targets are KEYWORDS="amd64 arm arm64 ppc ppc64 x86" I can stabilize on all those arches, but would rather the arch teams do it because its a second set of eyes.
Unable to check for sanity: > no match for package: net-libs/mbedtls-2.22.0
(In reply to NATTkA bot from comment #3) > Unable to check for sanity: > > > no match for package: net-libs/mbedtls-2.22.0 The bot was too quick. I just added it.
All sanity-check issues have been resolved
(In reply to NATTkA bot from comment #5) > All sanity-check issues have been resolved Oh sorry, it looks like I had some network problem when I pushed --- NOW its on the tree.
(In reply to Anthony Basile from comment #2) > > > - <2.7.14 (2.7.x not in tree) > > Correct, this is not in the tree. > > > > - <2.16.5 (2.16.x not in tree) > > 2.16.6 *is* in the tree and stable. > > > > - <2.21.0 > > I just added 2.22.0. We do have 2.19.1-r2 stable and it should be removed > in favor of 2.22.0, so let's begin a rapid stabilization on it. > > @arch teams, the targets are > > KEYWORDS="amd64 arm arm64 ppc ppc64 x86" > > I can stabilize on all those arches, but would rather the arch teams do it > because its a second set of eyes. Thanks for this. My comment predated 2.16.6 being added, sorry for the confusion.
Like the other subslot being requested stable, mbedtls is still broken for all USE=doc builds in this newest version as well, therefore at least arm64 is refusing to stabilize due to that too, in addition to the test failures.
(In reply to Mart Raudsepp from comment #8) > Like the other subslot being requested stable, mbedtls is still broken for > all USE=doc builds in this newest version as well, therefore at least arm64 > is refusing to stabilize due to that too, in addition to the test failures. leio, can you tell me what needs to be done for USE=doc, I'm confused about this.
(In reply to Anthony Basile from comment #9) > (In reply to Mart Raudsepp from comment #8) > > Like the other subslot being requested stable, mbedtls is still broken for > > all USE=doc builds in this newest version as well, therefore at least arm64 > > is refusing to stabilize due to that too, in addition to the test failures. > > leio, can you tell me what needs to be done for USE=doc, I'm confused about > this. USE=doc is fixed. Thanks to floppym.
[stuffing another bug into the summary/alias; doesn't change any of what needs to be done here.] @maintainer(s), there's still a test failure blocking the bug so arches won't touch it. Could you have a poke at it?
(In reply to Sam James (sec padawan) from comment #11) > [stuffing another bug into the summary/alias; doesn't change any of what > needs to be done here.] > > @maintainer(s), there's still a test failure blocking the bug so arches > won't touch it. Could you have a poke at it? "An issue was discovered in Arm Mbed TLS before 2.16.6 and 2.7.x before 2.7.15. An attacker that can get precise enough side-channel measurements can recover the long-term ECDSA private key by (1) reconstructing the projective coordinate of the result of scalar multiplication by exploiting side channels in the conversion to affine coordinates; (2) using an attack described by Naccache, Smart, and Stern in 2003 to recover a few bits of the ephemeral scalar from those projective coordinates via several measurements; and (3) using a lattice attack to get from there to the long-term ECDSA private key used for the signatures. Typically an attacker would have sufficient access when attacking an SGX enclave and controlling the untrusted OS." https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2020-04
x86 stable
@arches, please proceed with stabilisation. The test failures in bug 718390 are in an experimental/evaluation API, not yet ready for production use; they are to be ignored.
arm64 stable
(In reply to NATTkA bot from comment #16) > Unable to check for sanity: > > > no match for package: net-libs/mbedtls-2.22.0 @arch teams. sorry we need to restart stabilization with mbedtls-2.22.0-r1. I've acted on upstream bug https://github.com/ARMmbed/mbedtls/issues/3291.
amd64 stable
arm stable
ppc stable
ppc64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a75bfcf78192b3c2341ef8b93416e05388ab202c commit a75bfcf78192b3c2341ef8b93416e05388ab202c Author: Jakov Smolic <jakov.smolic@sartura.hr> AuthorDate: 2020-05-24 11:26:40 +0000 Commit: Anthony G. Basile <blueness@gentoo.org> CommitDate: 2020-05-25 21:22:43 +0000 net-libs/mbedtls: security cleanup Bug: https://bugs.gentoo.org/714582 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Jakov Smolic <jakov.smolic@sartura.hr> Signed-off-by: Anthony G. Basile <blueness@gentoo.org> net-libs/mbedtls/Manifest | 2 - net-libs/mbedtls/mbedtls-2.19.1-r2.ebuild | 106 ------------------------------ 2 files changed, 108 deletions(-)
(In reply to Agostino Sarubbo from comment #24) > x86 stable. > > Maintainer(s), please cleanup. > Security, please vote. clean up done.