lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: OFFTOPIC Re: OpenLinux: Multiple vulnerabilities have reported in Ethereal 0.9.12 OFFTOPIC 

On Mon, 10 Nov 2003 21:47:38 MST, Kurt Seifried said:
> OFFTOPIC
> 
> The last three were only fixed recently (like a week ago). I'm sorry but
> Ethereal is not a critical package.

No, the CVE numbers fixed by the upgrade to .15 mentioned in RedHat's advisory
were: CAN-2003-0925 CAN-2003-0926 CAN-2003-0927

The ones SCO fixed were: CAN-2003-0428 CAN-2003-0429 CAN-2003-0430 CAN-2003-0431 CAN-2003-0432
fixed by upgrading their code base to the .13 level.

And yes, it's not like a hole in Apache or other massively critical or
easy to exploit packages.

My original query still stands:

> Vendors have finite resources, they have to allocate them appropriately, for
> most this does not mean ethereal.

At what point should a vendor give up and *not* issue an advisory when
they fix something, especially for a "non-critical" package?

If a vendor is taking *months* to turn around security fixes that other
vendors are turning around in *days*, what's that saying about the vendor's
supply of finite resources?  At what point does the bad PR in being obviously
slow outweigh the benefits to the vendor's users in publishing an advisory
for a minor package?

> News at 9: Debian fixes epic4 IRC client, flaws originally fixed in May of
> 2003. End of world film at 11. I suppose we should castigate Debian for
> placing the a huge number of users at risk via a remote flaw in it. Or maybe
> not.

This will depend on whether you think that a distribution with corporate
support should be held to a higher standard than a volunteer free project.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031111/ed3c8844/attachment.bin

Powered by blists - more mailing lists