Summary: | <dev-libs/libgcrypt-1.5.4: Possible side-channel attack on ElGamal encryption subkeys (CVE-2014-5270) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Kristian Fiskerstrand (RETIRED) <k_f> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alonbl, crypto+disabled, multilib+disabled |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://lists.gnupg.org/pipermail/gnupg-users/2014-August/050440.html | ||
Whiteboard: | A3 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Kristian Fiskerstrand (RETIRED)
2014-08-08 10:42:08 UTC
Arches, please stabilize =dev-libs/libgcrypt-1.5.4 Target stable keywords: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 Why does 1.5.4 have a different SLOT? It conflicts with 1.5.3 on /usr/lib/libgcrypt.so.11 (In reply to Jeroen Roovers from comment #2) > Why does 1.5.4 have a different SLOT? It conflicts with 1.5.3 on > /usr/lib/libgcrypt.so.11 indeed... it was a copy of[1], added due to bug#513718 it probably a mistake. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/libgcrypt-1.5.3-r100.ebuild?hideattic=0&revision=1.5&view=markup Seems to be intentional: !dev-libs/libgcrypt:0/11 Multilib, why do we use slots such as this? or I should revert bug#513718 changes? ok, deferred multilib changes to later (libgcrypt-1.5.4-r100). libgcrypt-1.5.4 is exact copy of libgcrypt-1.5.3 now. The SLOT=11 contains just the library for pre-built software compatibility, i.e. that you can install 1.6* and 1.5* at the same time because you want to use 1.6* but some binary software was linked to .so.11. (In reply to Michał Górny from comment #6) > The SLOT=11 contains just the library for pre-built software compatibility, > i.e. that you can install 1.6* and 1.5* at the same time because you want to > use 1.6* but some binary software was linked to .so.11. Do we need to keep this forever? (In reply to Alon Bar-Lev from comment #7) > (In reply to Michał Górny from comment #6) > > The SLOT=11 contains just the library for pre-built software compatibility, > > i.e. that you can install 1.6* and 1.5* at the same time because you want to > > use 1.6* but some binary software was linked to .so.11. > > Do we need to keep this forever? No, just as long as there are binary packages that require it :). $ grep -R -l libgcrypt.*:11 app-emulation/emul-linux-x86-baselibs-20140406-r4 app-emulation/emul-linux-x86-baselibs-20140508-r12 app-emulation/emul-linux-x86-baselibs-20140508-r13 app-emulation/emul-linux-x86-baselibs-20140508-r14 app-emulation/emul-linux-x86-baselibs-20140508-r9 dev-db/xtrabackup-bin-2.1.9 dev-db/xtrabackup-bin-2.2.3 media-sound/spotify-0.9.11.27 media-sound/spotify-0.9.4.183-r8 www-client/google-chrome-36.0.1985.125_p1 Stable for HPPA. ppc stable ppc64 stable amd64 stable x86 stable sparc stable arm stable ia64 stable alpha stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one. New GLSA request filed. Cleanup done: + 24 Aug 2014; Kristian Fiskerstrand <k_f@gentoo.org> -libgcrypt-1.5.3.ebuild: + Cleanup vulnerable versions for security bug #519396 This issue was resolved and addressed in GLSA 201408-10 at http://security.gentoo.org/glsa/glsa-201408-10.xml by GLSA coordinator Kristian Fiskerstrand (K_F). |