Re: [GNUnet-developers] Why old-school C?

[Christian Grothoff]

On 07/08/2015 10:50 PM, Ed Baskerville wrote:
> Hi Christian,
> 
> Thanks for the quick response!
> 
> On Jul 8, 2015, at 12:50 PM, Christian Grothoff <address@hidden>
> wrote:
> 
>> Just to cut this short: We have gnunet-java, gnunet-python
>> (admittedly not much there yet), some people started gnunet-ruby
>> and gnunet-rust. GNUnet is a multi-process system, so each service
>> can be written (or re-written) in any language.  You fancy Go or
>> Haskell or OCAML instead, go for it.
> 
> That all sounds great, but I still worry about the main reference
> implementation continuing in that style. If a killer app emerges to
> drive adoption--say, a social networking app--one implementation will
> be much more widespread than the others, and whatever vulnerabilities
> are there will be the ones that get attacked.

The "reference implementation" for SMC-voting is in Java. If anyone
writes any component 'better' than what we have, it'll be the new
"reference implementation" for that component. So get hacking ;-).

>> 3) don't expect C hackers to switch to Haskell, or Java developers
>> to Go, the resulting loss of personal productivity is unlikely to
>> work out in anybody's favor.
> 
> To be fair, I wasn't proposing a switch from C per se, but suggesting
> that things could be done, even in C, in a safer way, with opaque
> data types and abstracted-away memory management.

Eh, we do use opaque data types *a lot*, and there are functions like
GNUNET_asprintf() that provide higher-level abstractions for
memory-management than your typical libc.   If you want to turn 'free()'
into a nop and try running with a conservative GC instead, good luck ---
but that's not an architectural change ;-).

> I also think that
> short-term losses in programmer productivity can sometimes be worth
> it in the long run, but I see your point.
> 
>> So please, go ahead, make it safer (even though I personally think
>> the choice of language is not the most critical security issue
>> today)
> 
> Would you mind quickly summarizing why we shouldn't worry too much
> about language choice--or, more specifically, raw pointers to
> structs, manual dereferencing, and manual memory allocation? Nicely
> separated processes?

Nicely separated processes, yes, but also forthcoming apparmor profiles,
static analysis & reasonably disciplined development.

>> Furthermore, if you re-write any existing subsystem in a way that
>> is clearly superior, we'll simply swap one binary for another and
>> everybody will be happy.  GNUnet is primarily a (large) set of
>> protocols --- between peers and between processes, and I don't care
>> too much about which (libre) language the components are written
>> in, as long as they are written well (and perform reasonably
>> well).
> 
> This is a side note, but to get GNUnet to work on non-jailbroken
> iOS--which some people probably don't care about but I think is going
> to be necessary--there needs to be a version that can run in a single
> process. iOS just won't let you do multiple processes unless you're
> Apple. This might not be too hard--just put processes on different
> threads, and use the same IPC--but there are no doubt implications
> for stability and security. I may end up attempting this after I'm
> better oriented, and would certainly appreciate any warnings you have
> on this front.

Sounds painful. iOS users should jailbreak their devices (i.e. by
installing a libre OS). Without that, they don't get reasonable security
or privacy or liberty. But sure, if you're already powned by Apple,
multi-process won't help that much either so you could just run
everything in one process with threads. ;-).

signature.asc
Description: OpenPGP digital signature