Oh, no, please not again. Are we going to talk one more fucking time
about the ethics of 0-days? Please no.
Is a delay of a year before reporting to the vendor, acceptable?
Thanks, Paul
Paul Szabo p...@maths.usyd.edu.au
http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and
I was suddenly reminded of this...
http://www.quickmeme.com/meme/3qicaz/
On Sat, Apr 20, 2013 at 1:05 PM, Joxean Koret joxeanko...@yahoo.es wrote:
Oh, no, please not again. Are we going to talk one more fucking time
about the ethics of 0-days? Please no.
Is a delay of a year before reporting
valdis.kletni...@vt.edu wrote:
On Fri, 19 Apr 2013 12:30:12 -0400, l3thal said:
looks like you are still at it heh...
procmail is your friend.
would work even better if people didn't make copies of the entire mail
and adding their little complaint.
I really wonder if they even read the lists they spam
2013/4/19 l3thal l3t...@smashthestack.org
looks like you are still at it heh...
On Fri, Apr 19, 2013 at 11:12 AM, secur...@mandriva.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yeah it is when you are in the business of selling exploits.
2013/4/19 paul.sz...@sydney.edu.au
VUPEN Security Research advisor...@vupen.com wrote in
http://www.securityfocus.com/archive/1/526402
:
X. DISCLOSURE TIMELINE
2012-02-15 - Vulnerability Discovered by VUPEN
2013-03-06 -
Why instead of discussing about ethics about 0days, don't you discuss about
responsible DEVELOPMENT instead?
If products where properly designed and developed there wouldn't be 0days
for them, would them?
- sergio
On Apr 20, 2013 2:17 PM, Mario Vilas mvi...@gmail.com wrote:
I was suddenly
On 4/20/13, Sergio Alvarez shad...@gmail.com wrote:
Why instead of discussing about ethics about 0days, don't you discuss about
responsible DEVELOPMENT instead?
If products where properly designed and developed there wouldn't be 0days
for them, would them?
Only if the designers developers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -
Debian Security Advisory DSA-2660-1 secur...@debian.org
http://www.debian.org/security/ Salvatore Bonaccorso
April 20, 2013
Hello list!
Last year I've disclosed vulnerabilities in JW Player and in RokBox. Which
were fixed by the developers - JW Player developers fixed one hole and
promised to fix others later and RokBox fixed all holes (but it was
questionable how they fixed holes related to JW Player).
In
The code monkeys can make mistakes as long as there is a process to
detect and remedy their mistakes before things get shipped. Hiring
decent application security researchers to audit their code would be a
good start.
On Sat, Apr 20, 2013 at 09:51:40AM -0400, Lee wrote:
On 4/20/13, Sergio
Yes, after the people that can make mistakes, we should have people that
are incapable of making mistakes. I totally agree, what a good idea.
On Sat, Apr 20, 2013 at 10:28 PM, Bryan br...@unhwildhats.com wrote:
The code monkeys can make mistakes as long as there is a process to
detect and
Let me expand on that, otherwise I'm sure it's unclear.
Is your suggestion, to remove the worry of developers making mistakes, to
add another human process after it and rely on this to remove all mistakes?
On Sat, Apr 20, 2013 at 10:54 PM, Benji m...@b3nji.com wrote:
Yes, after the people
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
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
(in my opinion)
On Sat, Apr 20, 2013 at 11:42 PM, Benji m...@b3nji.com 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
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
Your proposition was that developers will always make mistakes and
introduce stupid problems, so a QA team/process is necessary. While I agree
that there should be a QA/'audit' at some point, it shouldnt be the stage
that is relied on. Applications that are flawed from the design stage
onwards
Your 5-chained-0day-to-code-exec, in my opinion, does not count as
negligence and comes from the developer effectively not being a
security engineer
Solution: Hire security engineers.
In my opinion we are not at the stage in industry where we can
consider/expect any developer to think through
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.
On Sun, Apr 21, 2013 at 12:34 AM, Bryan
(For example,
http://webcache.googleusercontent.com/search?q=cache:2cXGaaHnqyMJ:www.computerworld.com/s/article/9235954/Researchers_find_critical_vulnerabilities_in_Java_7_Update_11+cd=8hl=enct=clnkgl=uk)
On Sun, Apr 21, 2013 at 12:37 AM, Benji m...@b3nji.com wrote:
Because security engineers
Sorry, by flaws, I should have said, *has not prevent bad code/ineffective
patches from being pushed out
On Sun, Apr 21, 2013 at 12:41 AM, Benji m...@b3nji.com wrote:
(For example,
Hahahahahaha. Sorry.
Yes, a better idea would be to educate and inform developers.
signature.asc
Description: This is a digitally signed message part
___
Full-Disclosure - We believe in it.
Charter:
The only point that I was trying to make is that there needs to be
more of an investement in the security facet of software development,
and that if a company is not willing to invest the resources to
create a secure product, not to whine when they get hacked.
On Sun, Apr 21, 2013 at 12:43:15AM
On Sat, 20 Apr 2013 20:02:12 -0400, Bryan said:
The only point that I was trying to make is that there needs to be
more of an investement in the security facet of software development,
and that if a company is not willing to invest the resources to
create a secure product, not to whine when
24 matches
Mail list logo
