I'm a big fan of full disclosure regarding security vulnerabilities discovered in software or in hardware. The meaning behind full disclosure is often different following with who you are talking about. Of course, responsible disclosure is often a good thing to give the time to the hardware/software vendor or software author to fix the problem before publishing the vulnerability. The process of full disclosure should help to build better software or, at least, reduce the risks associated to a published vulnerability. But the process only works if the two parties are playing fair : the discoverer (the one who discovers the vulnerability) and the author (the one who wrote the vulnerable software/hardware). Please keep mind in the software world that the discoverer of a vulnerability can become the one who is writing vulnerable software. So humility is a keyword in the process of full/responsible security disclosure. In such case, the two parties should talk together and provide as much information as possible to solve the vulnerability. It would be nice if more and more security advisory include by default the process of solving the security issue too. Not only the vulnerability itself but the whole information how the vulnerability was introduced, how it was (could be) solved and the scope of the resolution. I just make this comment because that could be an interesting paper/presentation to submit for the hack.lu 2007 conference taking place in Luxembourg in October 2007. The post is a kind of advertisement for the current call for paper and call for poster. Disclaimer : I'm involved in the conference ;-)
Tags: security conference luxembourg security_conference disclosure
![[FSF
Associate Member]](http://www.foo.be/fsfbutton-adulau.png){kind=small}
