On Thursday 12 February 2009 07:52:08 Alpt wrote: > What about the shrinking factor? Isn't it better to just use openssl as an > external library to minimize the size of our python binary?
Well yes, we can use the same pattern used to manage iproute. > Keep in mind that crypto stuff couldn't be necessary for the ntk > protocol[*], but only for ANDNA, Carciofo. Thus, it would be possible to > run ntkd without openssl. This could be of some benefit for some small > Acces Points. We can also manage the crypto stuff as an external module, so it can be installed only if needed. > [*] Unless we implement the secure QSPN and require it as necessary. > > What is the most size-savy solution? I don't know now, we should start to strip the python interpreter and test it. Only then, with real data, we can have an idea for the better solution, IMHO. > ~> On Wednesday 11 February 2009 14:49:11 Francesco Losciale wrote: > ~> > the purpose is to implement a small lib/crypto.py module that could be > ~> > usefull for several jobs, such as the ANDNA cryptographic > ~> > ~> I don't think we need a crypto.py, why should we reinvent the wheel? :) > > Just organizing the code. Take a look at crypto.[ch] (old C version). It is > a thin wrapper to openssl. Advantages: 1) ntk-friendly function names 2) > more independent from any real crypto library you're going to use. (f.e. we > can use sha1 and md5 from the stdlib and the rest from Openssl) I looked them :) I'm +0 here. Since we said that, optionally, we have to schedule possibility to not ship crypto stuff isn't better to manage it outside ntk.lib? -- Eriol - *p = NULL; - EIBTI GPG Key ID 0B7C8A19 http://mornie.org _______________________________________________ Netsukuku mailing list [email protected] http://lists.dyne.org/mailman/listinfo/netsukuku
