It was a perfect example of a largely deployed application which utilises security engineers, and has pushed patches/code which was ineffective. My point was that bugs like that are a lot easier to sort in a design or development stage than after the fact when remediation time is tight, and that a 'QA' process of any type will not make up for developer mistakes.
Sent from my iPhone. On 22 Apr 2013, at 07:39, Jeffrey Walton <[email protected]> wrote: > On Sat, Apr 20, 2013 at 7:37 PM, Benji <[email protected]> wrote: >> Because security engineers are different to a QA department you originally >> suggested, and you seem to be very ideologist about the scenarios. As we've >> seen, Oracle's Java product has security engineers and this has not >> prevented flaws. > Oracle is probably not a good example since it leaves known flaws in > the code base. > > http://www.h-online.com/security/news/item/Java-7-Update-21-closes-security-holes-and-restricts-applets-1843558.html: > > The warnings for Java applets now come in two types: an applet that > has a valid certificate generates a warning dialog with the Java logo > in it and details of the applet's certificate, but an applet that is > signed with an invalid certificate, is unsigned or self-signed, will > generate a warning with a yellow shield and warning triangle which is > designed to recommend that the applet should not be run. There is a > problem though with the certificate checking; as The H reported in > March, criminals were using revoked certificates as part of their > attacks and the Java runtime was doing nothing to check the validity > of certificates. On the latest update of Java, this has not changed > either; online validation and revocation checks are still off by > default. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
