On Mon, Feb 14, 2011 at 3:04 PM, Andrey Riabushenko <cd...@bk.ru> wrote: >> Well, I don't see how you could remove eet cipher and signature >> functionnality without impacting eet internals.
> Change is inevitable and imminent :) Though, It can wait for EFL 2.x > branch opening for API changing commits. You will have to wait for some years for EFL 2.x branch. And this is a serious statement, we are not going to break our API/ABI soon, that's all the reason we did a 1.0. >> Signature need to manipulate the internal data of the mapped file. >> That would means exposing this function as a callback in eet_open (if >> a file is not properly signed, it should not be open at all). >> As for cipher, you will see that it is used directly inside >> eet_data.c code. In fact for easier/lighter maintainance we do share >> code. > The API change in rather minor. User have to call > eet_signature_init() -- to sign functionality to work > eet_cipher_init() -- for ciphering > These calls register callbacks that are called during eet_open. Hence, > if eet_signature_init() was called, signature is checked and ignored > otherwise. That's an API/ABI change we can't accept at this point. Signature should not be ignored for user expecting it to be checked. That would be a serious security regression. >> > I do understand that I can build eet myself with "configure >> > --disable-gnutls --disable-openssl". But packagers of binary linux >> > distributions can't do it. >> > >> > I don't mind to write such patch myself if the idea will be >> > accepted. >> >> Last point I do think we should use more signature and cipher in the >> futur. Signature for theme and background edje would be a nice feature >> to be sure that the content you are downloading wasn't altered (Need >> to be implemented in exchange replacement). >> As for cipher, some configuration should be stored inside a secure >> wallet, and the plan is to use eet for that. > Please don't do that I clearly remember how annoying was KDE wallet. I > am happy that I don't use KDE now. At some point, you want to store password and other confidential information securely. That means using cipher and I don't see how you can go around a wallet. As for the implementation, the idea is to integrate it with PAM, so it doesn't require a second password, but that's not that easy to implement. >> use much of eet cipher/signature functionnality (I do use it a lot in >> elixir JS bindings), it should be more useful in the futur. > Great we have found one user of this functionality ;) And now, some may be using it outside of this svn. -- Cedric BAIL ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
