embargo ends Sept 11th 2013
It's past the embargo date you specified and there is no information in this bug as to which package has a vulnerability, much less any information about the vulnerability. It defeats the purpose of having a restricted bug. Unrestricting the bug and will close it invalid in 48 hours if more information is not provided.
(In reply to Sean Amoss from comment #1) > It's past the embargo date you specified and there is no information in this > bug as to which package has a vulnerability, much less any information about > the vulnerability. It defeats the purpose of having a restricted bug. > > Unrestricting the bug and will close it invalid in 48 hours if more > information is not provided. Embargo has been pushed back to Sept 18th by the vendor. I would provide some information on the bug that I can but now that its unrestricted I can't.
(In reply to Doug Goldstein from comment #2) > Embargo has been pushed back to Sept 18th by the vendor. I would provide > some information on the bug that I can but now that its unrestricted I can't. We are talked about this issue. Unless you provide some useful info, this bug will be marked as INVALID. Reporting restricted bugs about some vulnerability in some product is counter-productive. Either provide info in RESTRICTED bug, which contents we, as a security team will keep in private for a certain date, or do not file such bugs at our bugzilla at all.
Let's all relax. What I agreed to said I would not disclose any information to people not on the list which apparently no one from security@gentoo.org is on. I needed clarification before I could fill details in, telling me that you won't disclose information is not good enough until I got clarification. By the time I did this bug was marked unrestricted so I couldn't add any information. This is the first time I'm getting back to it now that its toggled restricted again. This bug was primarily made not for security@gentoo.org but for the maintainer of this package to coordinate with me on bug #484488 for stabilization. This bug is for polkit. We'll have this be to stabilize polkit-0.110-r1 but add polkit-0.112 for the ~arch users.
Are we waiting until the embargo ends to stable sys-auth/polkit-0.110-r1 ?
Embargo over, hit oss-security yesterday. Ready to stable?
(In reply to Chris Reffett from comment #6) > Embargo over, hit oss-security yesterday. Ready to stable? Yes. target version: 0.110-r1
(In reply to Doug Goldstein from comment #7) > (In reply to Chris Reffett from comment #6) > > Embargo over, hit oss-security yesterday. Ready to stable? > > Yes. > > target version: 0.110-r1 lets do 0.112 instead (I wanted 0.111 stable anyways and 0.112 is not much more than 0.111 + the patch)
amd64 stable
x86 stable
arm stable
ppc stable
ppc64 stable
ia64 stable
alpha stable
sparc stable
SH is not anymore a stable arch, removing it from the cc list
S390 is not anymore a stable arch, removing it from the cc list
Added to existing GLSA request.
CVE-2013-4288 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4288): Race condition in PolicyKit (aka polkit) allows local users to bypass intended PolicyKit restrictions and gain privileges by starting a setuid or pkexec process before the authorization check is performed, related to (1) the polkit_unix_process_new API function, (2) the dbus API, or (3) the --process (unix-process) option for authorization to pkcheck.
This issue was resolved and addressed in GLSA 201406-27 at http://security.gentoo.org/glsa/glsa-201406-27.xml by GLSA coordinator Chris Reffett (creffett).
