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 <[email protected]> > 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
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
