| Summary: | =dev-libs/libgcrypt-1.6.3-r4 stable request | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matthew Thode ( prometheanfire ) <prometheanfire> |
| Component: | [OLD] Keywording and Stabilization | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alonbl, arm64, luke, m68k, pacho, s390, sh+disabled, vmware+disabled |
| Priority: | Normal | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 494638, 533270, 559132, 559754 | ||
| Bug Blocks: | 541564, 552936 | ||
|
Description
Matthew Thode ( prometheanfire )
2015-02-02 00:25:11 UTC
please CC arches if you agree :D I would be fine with dev-libs/libgcrypt-1.6.2. What do you say Alon? (In reply to Kristian Fiskerstrand from comment #2) > I would be fine with dev-libs/libgcrypt-1.6.2. What do you say Alon? yes, I do not expect smooth transfer... please do this only when you have time to handle the side effects... Note that 1.6.3 was just released with security fixes for two side channel attacks. I just built this as part of keywording bug 546478 on alpha. Are we ready to stabilize? (In reply to Matt Turner from comment #5) > I just built this as part of keywording bug 546478 on alpha. Are we ready to > stabilize? I'm going to proceed to do stabilize ppc and ppc64 first, with full rev dep testing. Then arm and then I'll do amd64 and x86. I was not able to hit bug #528514 but when I get to x86, we'll see. KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ppc ppc64 s390 sh sparc x86" stable for ppc and ppc64. amd64 stable x86 stable (In reply to Anthony Basile from comment #6) > (In reply to Matt Turner from comment #5) > > I just built this as part of keywording bug 546478 on alpha. Are we ready to > > stabilize? > > I'm going to proceed to do stabilize ppc and ppc64 first, with full rev dep > testing. Then arm and then I'll do amd64 and x86. I was not able to hit > bug #528514 but when I get to x86, we'll see. I don't consider 528514 a blocker because it was reproduced with the actual stable libgcrypt. Stable for HPPA. Stable on alpha. (In reply to Matthew Thode ( prometheanfire ) from comment #0) > As a note for the eventual removal of 1.5.4, > only two packages I can see > need it. At the moment, [vmware overlay] app-emulation/vmware-workstation-11.1.2.2780323-r3.ebuild also depends upon dev-libs/libgcrypt-1.5.4-r100:11/11 . Thanks. (In reply to Manfred Knick from comment #13) > > [vmware overlay] app-emulation/vmware-workstation-11.1.2.2780323-r3.ebuild > also depends upon > dev-libs/libgcrypt-1.5.4-r100:11/11 . Well this popped up because I'm unbundling the libraries there (will go into the main tree sometime soon). Either I undo that, or we need the binary-only slot 11 to stick around. (Preferably stabilized at the same time as 1.6, since otherwise Portage silently prevents the libgcrypt upgrade for vmware users on stable systems.) (In reply to Andreas K. Hüttel from comment #14) > (Preferably stabilized at the same time as 1.6, since otherwise Portage > silently prevents the libgcrypt upgrade for vmware users on stable systems.) 1.6 is already stable in most archs, and vmware-workstation is none stable anyway. we keep the r100 only for vmware. (In reply to Alon Bar-Lev from comment #15) > (In reply to Andreas K. Hüttel from comment #14) > > (Preferably stabilized at the same time as 1.6, since otherwise Portage > > silently prevents the libgcrypt upgrade for vmware users on stable systems.) > > 1.6 is already stable in most archs, and vmware-workstation is none stable > anyway. we keep the r100 only for vmware. I see no issue doing that for now, but 1.5 is no longer maintained upstream and is already missing fixes for at least three known security matters, c.f. bug 541564 and bug 559942. The severity of these doesn't merit dropping support for 1.5 at this point, but it certainly would be discouraged and future issues are likely not to be backported. (In reply to Kristian Fiskerstrand from comment #16) > (In reply to Alon Bar-Lev from comment #15) > > (In reply to Andreas K. Hüttel from comment #14) > > > (Preferably stabilized at the same time as 1.6, since otherwise Portage > > > silently prevents the libgcrypt upgrade for vmware users on stable systems.) > > > > 1.6 is already stable in most archs, and vmware-workstation is none stable > > anyway. we keep the r100 only for vmware. > > I see no issue doing that for now, but 1.5 is no longer maintained upstream > and is already missing fixes for at least three known security matters, c.f. > bug 541564 and bug 559942. The severity of these doesn't merit dropping > support for 1.5 at this point, but it certainly would be discouraged and > future issues are likely not to be backported. Granted; the issue here is the same if a bundled version is used, it is just less transparent in that case. (In reply to Alon Bar-Lev from comment #15) > (In reply to Andreas K. Hüttel from comment #14) > > (Preferably stabilized at the same time as 1.6, since otherwise Portage > > silently prevents the libgcrypt upgrade for vmware users on stable systems.) > > 1.6 is already stable in most archs, and vmware-workstation is none stable > anyway. we keep the r100 only for vmware. Which already means that (without manual keywording of the r100) the vmware users just dont upgrade to 1.6 (the upgrade is silently dropped by emerge). Probably I should add some has_version to the vmware ebuilds so people are warned about this. (In reply to Andreas K. Hüttel from comment #18) > (In reply to Alon Bar-Lev from comment #15) > > (In reply to Andreas K. Hüttel from comment #14) > > > (Preferably stabilized at the same time as 1.6, since otherwise Portage > > > silently prevents the libgcrypt upgrade for vmware users on stable systems.) > > > > 1.6 is already stable in most archs, and vmware-workstation is none stable > > anyway. we keep the r100 only for vmware. > > Which already means that (without manual keywording of the r100) the vmware > users just dont upgrade to 1.6 (the upgrade is silently dropped by emerge). > Probably I should add some has_version to the vmware ebuilds so people are > warned about this. I never been there, but as far as I know slot 0 will be updated to latest on that slot. (In reply to Alon Bar-Lev from comment #19) > (In reply to Andreas K. Hüttel from comment #18) > > (In reply to Alon Bar-Lev from comment #15) > > > (In reply to Andreas K. Hüttel from comment #14) > > > > (Preferably stabilized at the same time as 1.6, since otherwise Portage > > > > silently prevents the libgcrypt upgrade for vmware users on stable systems.) > > > > > > 1.6 is already stable in most archs, and vmware-workstation is none stable > > > anyway. we keep the r100 only for vmware. > > > > Which already means that (without manual keywording of the r100) the vmware > > users just dont upgrade to 1.6 (the upgrade is silently dropped by emerge). > > Probably I should add some has_version to the vmware ebuilds so people are > > warned about this. > > I never been there, but as far as I know slot 0 will be updated to latest on > that slot. Yup, it is under a separate slot so shouldn't cause any run-time issues as long as we dont run into a security vulnerability down the road that is non-trivial to backport. sparc stable The remaining arches are arm64, ia64, m68k s390 and sh. But these are not stable arches. Shall we close this bug? (In reply to Anthony Basile from comment #22) > The remaining arches are arm64, ia64, m68k s390 and sh. But these are not > stable arches. Shall we close this bug? I'm sorry, ia64 is not an unstable arch. ia64 stable All stable (In reply to Mikle Kolyada from comment #24) > ia64 stable Thanks, all stable arches are then stabilized, closing this bug |