http://www.openssl.org/news/secadv_20140407.txt We should patch and repack Regards !
On 07/04/2014 21:54, Plonky Duby wrote:
http://www.openssl.org/news/secadv_20140407.txt
We should patch and repack
Regards !
This is already fixed by the 1.0.1g update. I've updated the wiki. -- Timothée Ravier
Am 08.04.2014 10:56, schrieb Timothée Ravier:
On 07/04/2014 21:54, Plonky Duby wrote:
http://www.openssl.org/news/secadv_20140407.txt
We should patch and repack
Regards !
This is already fixed by the 1.0.1g update. I've updated the wiki.
this bug hab been around much longer than 1d. it existed since openssl 1.0.1 which was released in march 2012. so affected versions are 1.0.1 - 1.0.1f
On 08/04/2014 11:33, G. Schlisio wrote:
this bug hab been around much longer than 1d. it existed since openssl 1.0.1 which was released in march 2012. so affected versions are 1.0.1 - 1.0.1f
Indeed, I'm updating the wiki. -- Timothée Ravier
On 08/04/14 19:39, Timothée Ravier wrote:
On 08/04/2014 11:33, G. Schlisio wrote:
this bug hab been around much longer than 1d. it existed since openssl 1.0.1 which was released in march 2012. so affected versions are 1.0.1 - 1.0.1f
Indeed, I'm updating the wiki.
[accidentally replied off list - resending] It was public for one day. I added this column in the wiki for tracking the responsiveness of the packagers to handling security issues to see where we can improve. Allan
On 08/04/2014 11:52, Allan McRae wrote:
It was public for one day. I added this column in the wiki for tracking the responsiveness of the packagers to handling security issues to see where we can improve.
Ok, I'm adding a note on this and reverting back to ~1d time vulnerable. -- Timothée Ravier
Am 08.04.2014 12:04, schrieb Timothée Ravier:
On 08/04/2014 11:52, Allan McRae wrote:
It was public for one day. I added this column in the wiki for tracking the responsiveness of the packagers to handling security issues to see where we can improve.
Ok, I'm adding a note on this and reverting back to ~1d time vulnerable.
the column is clearly named "time vulnerable", which is since march 2012. atm you seem to use it for the "time known" information. maybe add another column then, because a "time vulnerable" of more than 2 years means a totally other severity of such a bug than just a day. i think, this information should be easily visible.
On 08/04/14 23:08, G. Schlisio wrote:
Am 08.04.2014 12:04, schrieb Timothée Ravier:
On 08/04/2014 11:52, Allan McRae wrote:
It was public for one day. I added this column in the wiki for tracking the responsiveness of the packagers to handling security issues to see where we can improve.
Ok, I'm adding a note on this and reverting back to ~1d time vulnerable.
the column is clearly named "time vulnerable", which is since march 2012. atm you seem to use it for the "time known" information. maybe add another column then, because a "time vulnerable" of more than 2 years means a totally other severity of such a bug than just a day. i think, this information should be easily visible.
Why? Just list every piece of software since the day it was first released. That would be accurate.
Why? Just list every piece of software since the day it was first released. That would be accurate.
i'm not sure, we understand each other. if i understand you correct, you think, that vulns are in the software mainly from the beginning until they are fixed. but in this special case it was introduced with a new release. my point was, that the exposure time might be an important information. a long exposure like in this case means, that this vuln could have been exploited systematically, while an exposure time of a day makes widespread exploits far less likely.
On 08/04/2014 15:34, G. Schlisio wrote:
Why? Just list every piece of software since the day it was first released. That would be accurate.
i'm not sure, we understand each other. if i understand you correct, you think, that vulns are in the software mainly from the beginning until they are fixed. but in this special case it was introduced with a new release. my point was, that the exposure time might be an important information. a long exposure like in this case means, that this vuln could have been exploited systematically, while an exposure time of a day makes widespread exploits far less likely.
I agree with Allan here :
I added this column in the wiki for tracking the responsiveness of the packagers to handling security issues to see where we can improve.
What matters for us to track is the time it takes for us to notice and for Arch packagers to fix the issue once it has been disclosed. Finding how long a specific vulnerability has been available and exploitable is a generic information not related to Arch Linux. I'm not against adding it to the wiki as a separated column. By the way, there is another minor issue, the Update/Bug column has a double usage, maybe we should split this one in two. -- Timothée Ravier
I agree with Allan here :
I added this column in the wiki for tracking the responsiveness of the packagers to handling security issues to see where we can improve.
What matters for us to track is the time it takes for us to notice and for Arch packagers to fix the issue once it has been disclosed.
as a measure of arch linux' responsiveness i propose a title like "time known" or similar. i understand that this is an important thing to keep track of and fully support keeping this information. still, as an admin, i feel the importance of this "time vulnerable" (in the sense i explained bevore.
Finding how long a specific vulnerability has been available and exploitable is a generic information not related to Arch Linux.
I'm not against adding it to the wiki as a separated column.
By the way, there is another minor issue, the Update/Bug column has a double usage, maybe we should split this one in two.
any reason against splitting? for now we still have some space to the sides (at least at my setup). thanks for considering.
Suggestion: Concerning security issue that big like this, may be we can have a dedicated box on the front page of wiki to signal it and invite for update! What do you think about ? 2014-04-08 15:53 GMT+02:00 G. Schlisio <g.schlisio@dukun.de>:
I agree with Allan here :
I added this column in the wiki for tracking the responsiveness of the packagers to handling security issues to see where we can improve.
What matters for us to track is the time it takes for us to notice and for Arch packagers to fix the issue once it has been disclosed.
as a measure of arch linux' responsiveness i propose a title like "time known" or similar. i understand that this is an important thing to keep track of and fully support keeping this information. still, as an admin, i feel the importance of this "time vulnerable" (in the sense i explained bevore.
Finding how long a specific vulnerability has been available and exploitable is a generic information not related to Arch Linux.
I'm not against adding it to the wiki as a separated column.
By the way, there is another minor issue, the Update/Bug column has a double usage, maybe we should split this one in two.
any reason against splitting? for now we still have some space to the sides (at least at my setup).
thanks for considering.
_______________________________________________ arch-security mailing list arch-security@archlinux.org https://mailman.archlinux.org/mailman/listinfo/arch-security
participants (4)
-
Allan McRae
-
G. Schlisio
-
Plonky Duby
-
Timothée Ravier