From ${URL} : Slim 1.3.6 fixes a security flaw related to a potential NULL ptr. dereference when using crypt() from glibc 2.17+ (eglibc 2.17+). Without the fix, malformed or unsupported salts crash the login daemon. Upstream fix: http://git.berlios.de/cgi-bin/cgit.cgi/slim/commit/?id=fbdfae3b406b1bb6f4e5e440e79b9b8bb8f071fb @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
I dropped HPPA keywords on the older versions.
Oops, wrong bug.
(In reply to Jeroen Roovers from comment #2) > Oops, wrong bug. Resetting back to what it was.
New ebuild is in the tree. Given the amount of patchwork I had to do in the build system, I don't have as much confidence in this version as I've had in the past; if stabilization can wait 30 days that would be preferable, just to give it more testing time in the field.
(In reply to Ian Stakenvicius from comment #4) > New ebuild is in the tree. > > Given the amount of patchwork I had to do in the build system, I don't have > as much confidence in this version as I've had in the past; if stabilization > can wait 30 days that would be preferable, just to give it more testing time > in the field. To comply with our preferred 20 days of delay for an issue of this severity, I'd go for 15 days here max. For the future, to give users a clean upgrade path, security bumps should be as straight-forward as possible, so fixing other (build system?) issues that require more extensive testing should be done in a another revision of the package.
(In reply to Alex Legler from comment #5) > (In reply to Ian Stakenvicius from comment #4) > > New ebuild is in the tree. > > > > Given the amount of patchwork I had to do in the build system, I don't have > > as much confidence in this version as I've had in the past; if stabilization > > can wait 30 days that would be preferable, just to give it more testing time > > in the field. > > To comply with our preferred 20 days of delay for an issue of this severity, > I'd go for 15 days here max. > > For the future, to give users a clean upgrade path, security bumps should be > as straight-forward as possible, so fixing other (build system?) issues that > require more extensive testing should be done in a another revision of the > package. I agree. The issue here is that upstream changed around a fair bit of stuff between this new version and the previous one, and to be honest I have no idea how they could have released it in the state they did because as far as I could tell it just plain wouldn't build. From inspecting the code and testing locally, it seems like everything will still work fine, but this general lack of care by upstream this time around reduces my confidence that there aren't other hidden issues. 15 days should be fine, though. Thanks!
Given the other issues with slim-1.3.6, and chithead pointing out that the fix is actually a very simple backport, I decided to backport it and revbump slim-1.3.5. CC'ing arches to stabilize immediately: =x11-misc/slim-1.3.5-r4 : KEYWORDS="amd64 arm ppc ppc64 sparc x86"
amd64/ppc/ppc64/x86 stable
sparc stable. Maintainer(s), please cleanup. Security, please vote.
GLSA vote: no.
Cleanup complete.
Thanks for your work GLSA vote: no Closing as noglsa
