[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] TOR Fone - p2p secure and anonymous VoIP tool

> On Sun, Feb 3, 2013 at 9:14 AM, Softail <black98fxstc@xxxxxxxxx> wrote:
>> What is your objection to C++?
> Jacob is not great at C++, apparently.
> (there is nothing wrong with C++ used properly and done well... except
> the lack of an ABI; you win some you lose some ;)
> on a more on-topic note i do not expect to see usable VoIP over Tor
> until datagram transport(s) are implemented.  i'd love to be proved
> wrong...

My objection is that *many* people aren't very good at C or C++
programming. If they were, *trivial* memory corruption bugs wouldn't be
a problem, right? Sadly, this is an issue.

In a type safe specified language as well as a type safe aware compiler,
we see different bugs but usually we don't see classic bugs from the 80s
and 90s.

So Jitsi won't have those obvious memory corruption bugs but you can
probably own a jitsi user with a fake Sun/Oracle Java update. I think in
fact that EvilGrade had/has such a module for Java.

So I'd also want to see kernel hardening (AppArmor, seatbelt, SELinux
policies, etc) on any native code installed on the system.

Thus, any program written in say, Python or Java would have entire
classes of issues practically solved. Whereas in C or C++, we have both
basic memory issues and larger design flaws, there exists myriad of
issues on top of other issues. It is a lot of work to find some kinds of
complex bugs (say, subtle crypto issues), it is even more to have to
look for stack and heap overflows at every corner. That isn't to say
that you shouldn't look such issues. It is to say that Bob's first
program in C will likely have lots of extremely serious issues; the same
program in Python may have other serious issues but likely it isn't an
instant remote code execution issue.

All the best,
tor-talk mailing list