| 1 |
On Thu, Dec 15, 2016 at 4:43 PM, Yury German <blueknight@g.o> wrote: |
| 2 |
> The problem with that is that a GLSA check will fail at that point, we |
| 3 |
> can not also include the fix are (security project) in the fix section |
| 4 |
> as we do not know what version will be final on stabilization. For |
| 5 |
> example, if you look in Bug Tracker the bugs can go stable but to |
| 6 |
> stabilize them will take a very long time. Sometimes it takes as long |
| 7 |
> to stabilize them that a new version is out before the original is |
| 8 |
> stabilized. (Just a note, not blaming the arches groups here, it is |
| 9 |
> simple the way it is). What about the times that during stabilization |
| 10 |
> a dependency is found and it takes a month or two to fix it? The GLSA |
| 11 |
> goes out, it now tells the users to update to a version that does not |
| 12 |
> exist. |
| 13 |
|
| 14 |
You could send it out when the stablereq goes out. Then you know what |
| 15 |
the stable target is. Presumably any newer version would also contain |
| 16 |
the fix if for some reason it gets revbumped. |
| 17 |
|
| 18 |
It probably wouldn't hurt to send out a notice at the end of the |
| 19 |
deadline based upon the severity of the issue just to let people know |
| 20 |
they're vulnerable. That is, if a vulnerability normally has a 3 day |
| 21 |
target, then delay sending a notice until there is a stable request, |
| 22 |
or until 3 days elapse, whichever comes first. |
| 23 |
|
| 24 |
I feel like this is a contract with our users. If an issue allows |
| 25 |
running code remotely as root if a system package is installed, we |
| 26 |
promise to do something about it within a day. If for some reason we |
| 27 |
can't actually fix the bug within a day, then the least we can do is |
| 28 |
inform our users that we're breaking our promise. |
| 29 |
|
| 30 |
Otherwise we're giving a false sense of security to our users. If we |
| 31 |
can't actually uphold the targets in our vulnerability policy, then we |
| 32 |
should change the targets to something we can uphold. |
| 33 |
|
| 34 |
> |
| 35 |
> It does sound good, but not practical as it will introduce confusion |
| 36 |
> for the users especially those that do not constantly maintain their |
| 37 |
> system and only update the security patches. |
| 38 |
> |
| 39 |
|
| 40 |
Well, I suppose users might be confused if they have a vulnerability |
| 41 |
for a week or two with no sign of a fix. But, at least they'll know |
| 42 |
their systems are vulnerable the entire time. |
| 43 |
|
| 44 |
Is it really an improvement to just leave them in ignorance that |
| 45 |
they're running software with a known vulnerability? Hey, at least |
| 46 |
they won't be worried about it! |
| 47 |
|
| 48 |
> Those users that have a practice of updating (world update) on a schedule |
| 49 |
> (Weekly / Monthly) would receive the patches if the stable version is in the tree. |
| 50 |
|
| 51 |
These users have no need for glsa-check or notices in the first place. |
| 52 |
The whole point of those is to let you update security patches only |
| 53 |
more frequently than other updates. |
| 54 |
|
| 55 |
-- |
| 56 |
Rich |
Archives