On Mon, 14 Feb 2011 15:14:13 +0100 Cedric BAIL <[email protected]> said:
absolutely right. we CANT break the api. can't change so any existing app or code would break. that is the price of stability and the 1.0 release everyone has been screaming for for so long. now we've made our bed - we have to lay in it. too bad. that's reality. we can't break it. what we CAN do is maybe have less common features turned into runtime dlopen() efforts where now these dependencies become "soft dependencies". i.e. they are enabled IF the required libs get installed, which is the case currently - but only at compile time do you get to make that choice. distros CAN supply multiple versions of eet with different combinations of features - this is common. it's easy if we only have 1 or 2 thnigs, but once it's more, the only way is to provide all, or - the dlopen trick. now the dlopen trick... thats a world of discussion on its own. it's not totally straightforward as all the pkg-config and version checking done at compile-time we have to now move to runtime to work across many os's and distributions. there are a few ways to skin this cat - use dlopen only with a module infra - load a module that abstracts the dependency and this module links to the dependent lib - this is what evas does with engines and loaders. the other way is to directly dlopen the libs. anyway - that's a discussion for another thread and much more consideration. > On Mon, Feb 14, 2011 at 3:04 PM, Andrey Riabushenko <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
