When security issue is raised and stabilization request done to fix issue, it could takes days to have the package really stabilized. I don't know the reason, i will just suppose it's because of under staff arch testers. But in the meanwhile, most security report expose the hole and kinda gives a "howto abuse" documentation to everyone. So policy for stabilization request should be extend to allow someone/a dev/the maintainer of a package to query gentoo forum on stabilization request. If arch testers cannot provide answer : ask ~ users on forum to gave a big answer if a package works for them or not : some kind of temporary made all ~ users assume as arch tester. There's a little contradiction there, as many ~ users will report errors, so no bug open means the package is just working : but if you don't want assume that, ask them. Example (many must exist, but that's the only one i have seen) : https://bugs.gentoo.org/show_bug.cgi?id=493094 - 3.3. is latest stable since 29-11 with a security fix - security issue report 29-11 (cannot be faster) -> https://bugs.gentoo.org/show_bug.cgi?id=492876 - stabilization request 02-12 (acceptable delay) - As of today 12-16 : not any arch have stabilize it ! So after 15+ days, the security flaw is still there, and it will remain like that until arch testers get out of sleep. Reproducible: Always
sorry for dates mixing format, i have mix french "days-month" and english "month-days". Should be 11-29, 11-29, 12-02 & 12-16
We don't have the staff to implement this. Even if we had, your proposed process is questionable and bugzilla certainly not the forum to discuss this.
-(In reply to Alex Legler from comment #2) > We don't have the staff to implement this. I said the maintainer/dev, the one that open the bug for stabilization : you don't need more staff. >your proposed process is questionable If there is something that would raise a question, it should be "Do you prefer a package stabilize and trust users answer or leave a security hole in every system that use the affected program because arch testers is under staff?" > and bugzilla certainly not the forum to discuss this. If you want discuss this with other devs in your dev ML, it would be kind to post url to it so i could follow it.
> So policy for stabilization request should be extend to allow someone/a > dev/the maintainer of a package to query gentoo forum on stabilization > request. > If arch testers cannot provide answer : ask ~ users on forum to gave a big > answer if a package works for them or not : some kind of temporary made all > ~ users assume as arch tester. > There's a little contradiction there, as many ~ users will report errors, so > no bug open means the package is just working : but if you don't want assume > that, ask them. As arch teams developer i'd say, not all users have specific qa knowledges about how package *must work* If package just run it does not mean that it is OK. We don't know how users will test packages.
(In reply to Mikle Kolyada from comment #4) > As arch teams developer i'd say, not all users have specific qa knowledges > about how package *must work* If package just run it does not mean that it > is OK. We don't know how users will test packages. Agree. You cannot expect users answer better than "it works" or "it doesn't work", they aren't arch testers, so they will answer if the package works for them or not, they of course don't test any flags combos the package own. (That's my vision on how "arch testing" works, might be false. As i'm sure none have really time and hardware to test a kernel.) But having a stable package because most users answer "it works" is better than having a known version with security issue kept stable. I'm not asking to use that query on a stablereq for package, i'm asking to use it when a stablereq for package is done because of security issue. For me, a "less stable" package in tree is better than a stable one with security issue. In a ideal situation, package is test by arch testers and mark stable, and its stabilization fix the issue. But it's not an ideal situation, as for a reason (that i attribute to lack of arch testers), this in real doesn't works and package isn't mark stable for days, keeping the buggy version stable. Keeping that way of handling stablereq for security issue is just like if everyone is closing eyes on the problem, but keeping eyes closed won't magically remove security hole and won't add more arch testers to gentoo.
Having broken but security aware package is useless. There is no 'less stable' packages. They are either stable or not, period. We have already DO quick stabilization(without 30 days delay) on security stabilizing. If you want to help with it - we are always looking for arch testers. > Keeping that way of handling stablereq for security issue is just like if > everyone is closing eyes on the problem, but keeping eyes closed won't > magically remove security hole and won't add more arch testers to gentoo. True. But blindly stabilizing packages without proper testing ruins all idea of stable branch and it is not an option. I am saying that as arch team member(for 3 arches) and security team member. Anyway this is not proper place for discussions, gentoo-dev maillist[1] is. [1] - more details - http://www.gentoo.org/main/en/lists.xml
