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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 20 Apr 2013 18:58:52 -0400
From: Bryan <>
To: Benji <>
Cc: Full-Disclosure <>
Subject: Re: VUPEN Security Research - Adobe Flash Player
 RTMP Data Processing Object Confusion (CVE-2013-2555)

I think the definition of 'needless staff' highly depends on whether you
want 'vulnerable software'.

Educating current developers is absolutely a good idea, but still not
foolproof. The bottom line is that if you want safe software, you need
to invest in proper development. As far as I am concerned, for large
companies like Adobe and Oracle, where software bugs in your product
have a direct impact on the safety of your customers, that involves 
hiring specialized staff.

On Sat, Apr 20, 2013 at 11:49:22PM +0100, Benji wrote:
>    (in my opinion)
>    On Sat, Apr 20, 2013 at 11:42 PM, Benji <> wrote:
>      Yes, a better idea would be to educate and inform developers. At a
>      business level atleast this will a) save extra expenditure on needless
>      staff  and extra departments b) result in faster turn arounds as there's
>      then less time needed for remediation. At a technical level, it will
>      atleast result in less 'dumb' bugs (assuming training and education is
>      effective and relevant).
>      I think at this point expecting software to have 0 flaws or being under
>      the illusion that software will ever be flawless in it's current state
>      is like wishing really hard before bed every night that genetics and
>      evolution will make you a unicorn.
>      On Sat, Apr 20, 2013 at 11:35 PM, Bryan <> wrote:
>        I am just saying that developers and designers make mistakes and
>        that there is no getting around that. Rather than relying on the
>        benevolent 0day researchers from the sky publicly disclosing their
>        vulnerabilities, more responsible QA testing within the company will
>        prevent many of these vulnerabilities from occurring in the first
>        place. Or do you have a better idea?

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists