OTR and general security stuff
Jurre van Bergen
drwhax at 2600nl.net
Thu Feb 14 18:20:02 EST 2013
On 02/13/2013 05:22 PM, Ethan Blanton wrote:
>> I plan on;
>> * Audit the codebase.
>> * Writing some fuzzers and look what ASan/TSan/MSan think of it.
>> * Getting a better SSL implementation going (NSS/GNUTLS in a pluggable
>> way) 
> This ... seems to be confused. We already *have* NSS and GnuTLS in a
> pluggable way. In addition, the first bug report you cite in  was
> incorrect and needlessly inflammatory; the author read a tweet that
> was factually incorrect and flew off the handle.
> I won't suggest that our SSL support cannot be improved, as I'm sure
> it can, but I think your gross strategy may have to be reconsidered.
In that case, while there already is NSS/GnuTLS support in a pluggable
way, i'll look into older SSL tickets and come up with a proposal from
there to see what could be improved and how it could be improved, I
think the mailinglist is the best way to discuss that instead of a
ticket. I'll come up with remarks and post them on the devel list.
>> * Sandbox integration for Linux platform. Think libvirt-sandbox or Seccomp?
> This seems like something that shouldn't be folded into individual
> applications, but provided as part of the system.
The OS/kernel should provide a way to sandbox the application. In terms
of libvirt-sandbox, a way could be created automatically while
installing Pidgin to only allow running it in a sandbox, but this would
need to be scripted and delivered by Pidgin.
When it come's to Seccomp, there is native support in the 3.5.x kernel,
although you could add support for non 3.5 kernels using libseccomp.
It has quite matured. I really recommend reading the articles below.
Fun fact, chromium OS and browser has seccomp support and are considered
tough nuts to crack!
Give a man a fish and you feed him for a day; teach a man to fish and you feed him for life.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel