| 1 |
On Mon, 2007-04-16 at 08:32 -0500, Kurt Lieber wrote: |
| 2 |
> On 4/16/07, Calum <caluml@×××××.com> wrote: |
| 3 |
> > But the infrastructure is already in place for GLSA's. |
| 4 |
> |
| 5 |
> You have to chase |
| 6 |
> security people down to draft the GLSA. You have to chase more |
| 7 |
> security people down to peer review the GLSA. |
| 8 |
|
| 9 |
In my limited experience with vulnerabilities in packages I maintain. |
| 10 |
The problem or delays seem to be with the last two steps listed. Not to |
| 11 |
simplify them by any means, or the preceding steps. |
| 12 |
|
| 13 |
http://bugs.gentoo.org/show_bug.cgi?id=173122 |
| 14 |
http://bugs.gentoo.org/show_bug.cgi?id=169433 |
| 15 |
|
| 16 |
Not to mention in my case upstream had already acted or etc, so no |
| 17 |
patching or etc was needed on my behalf. Just bumps and stabilization if |
| 18 |
anything. |
| 19 |
|
| 20 |
> I don't know that we've ever formally quantified how much time an |
| 21 |
> average GLSA takes, but my semi-educated guess would be in the |
| 22 |
> neighborhood of 10 hours per package. |
| 23 |
|
| 24 |
I would not be surprised, and surely that if they have to follow it |
| 25 |
through from start to finish. Less if say maintaining devs are |
| 26 |
responsible for addressing their vulnerable package, and not leaving it |
| 27 |
up to others like security team. All must do their parts to get things |
| 28 |
done in a timely manner. |
| 29 |
|
| 30 |
> Now, take that process and multiply it by the number of -sources in |
| 31 |
> the tree and you can start to get an idea for how much time it takes |
| 32 |
> to issue kernel updates. |
| 33 |
|
| 34 |
Kernel issues must be a nightmare for the security team. |
| 35 |
|
| 36 |
> So, again, #gentoo-security is where you can start being part of the solution. |
| 37 |
|
| 38 |
If I had the time I would go join and help. As is, already quite over |
| 39 |
committed :) |
| 40 |
|
| 41 |
-- |
| 42 |
William L. Thomson Jr. |
| 43 |
Gentoo/Java |
Archives