[Evolution-hackers] evolution-kolab: using a TPM for SSL/TLS client certs
Hi all, ...the story continues... As a part of our project, we need to support TPM hardware as certificate source for client-authentication against client-auth-enabled services. Within Kolab context, these are mainly IMAPS, SMTPS, LDAPS and HTTPS. The tpm-tools suite and openCryptoki will serve as software layer between the TPM hardware and the NSS lib, talking to each other via the PKCS#11 protocol. We have validated already that the NSS lib can make use of certificates stored in the TPM via openCryptoki. In Evolution and E-D-S, I have seen references to PKCS#11 in S/Mime context only, so I assume there is no infrastructure for SSL/TLS client auth via NSS/PKCS#11 as yet. Is this correct? As far as the Camel lib goes, we have the situation that we will need to handle at least two instances. One in Evolution (which is there anyway) and at least one in the backends (E-D-S). As far as the EDS part goes, we would be able to configure NSS to use the TPM stack from within our plugin code. But foe Evo, I doubt it will be possible to do the same configuration from within the EPlugin, right? This would mean we needed to touch Evo code itself. Has anyone had any thoughts about this already? As for implementation, we thought it might be a good idea to implement the TPM stuff separately from the Kolab plugin. This would mean to leave Camel alone and to integrate TPM usage with the NSS lib directly. Do you think this would be an appropriate approach? Have there been any efforts before to do something like this? Questions galore, any input welcome. :-) Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] evolution-kolab: hiding IMAP folders
Hi all, ...still continuing... Kolab makes use of RFC5464 - The IMAP METADATA Extension IMAP folder annotations to differentiate between the various folder types which are handled by Kolab. Remember, anything (Email and PIM data) is stored as Email messages with XML attachments in IMAP folders within the Kolab context. This means, we have IMAP folders for Email, Calendars, Contacts, TODOs, Tasks and the like. Now, when creating a Kolab account, all of these folder types are generated on the server. There is at least one folder for each type, which is the default folder initially. From within Evolution, *only* the IMAP folder which is annotated Email should be visible and all others should be hidden, as their respective contents will be managed by the backends, not Evolution. Otherwise, users will be able to meddle with PIM data folders, which might result in disastrous situations on the server side. Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? Many greetings, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders
On tuesday 20 July 2010 Christian Hilberg wrote: [...] From within Evolution, *only* the IMAP folder which is annotated Email ^^ the IMAP folders which are annotated, this is. Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Couple new functions for ECal/EBook
On Tue, 2010-07-20 at 11:21 +0530, chen wrote: Is it required ? Having it in ECalBackendStore simplifies the backend code to form the path based on the type (calendar,tasks,memos) at a single place rather than every backend doing it.. Forming the path at a single place instead of all the backends doing it is definitely the goal. My thought was just that ECalBackend can do it as easily as ECalBackendStore, since ECalBackendStore does nothing else with the URI + type it's given and the path still has to be shared with ECalBackendCache somehow. Moving it to ECalBackend seemed cleaner to me, but I can try to keep things as is if you'd prefer to avoid the API break. Btw we could deprecate ECalBackendCache and update just ECalBackendStore. I thought of that, but evolution-mapi still uses ECalBackendCache pretty heavily. Should we give Bharath and Milan some time to migrate off it first? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders
On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: Hi all, ...still continuing... Kolab makes use of RFC5464 - The IMAP METADATA Extension IMAP folder annotations to differentiate between the various folder types which are handled by Kolab. Remember, anything (Email and PIM data) is stored as Email messages with XML attachments in IMAP folders within the Kolab context. This means, we have IMAP folders for Email, Calendars, Contacts, TODOs, Tasks and the like. Now, when creating a Kolab account, all of these folder types are generated on the server. There is at least one folder for each type, which is the default folder initially. From within Evolution, *only* the IMAP folder which is annotated Email should be visible and all others should be hidden, as their respective contents will be managed by the backends, not Evolution. Otherwise, users will be able to meddle with PIM data folders, which might result in disastrous situations on the server side. Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? This cannot be done in a fool-proof way for IMAP as it does not provide information on the type of the folder. This can be done with an assumption that calendar folder will be named as 'calendar' or contact folders as 'contacts'. The other thought I get is, the contacts+calendar folder names can be collected as an option in account-setup and set as part of camel url (prolly through a kolab plugin, hiding it from the user. you can check how groupwise account set-up is implemented for an example) say hide_folders=list of folders with a separator. If the parameter is set, the folders can be hidden while fetching folder_info through camel_store_get_folder_info (in imapx backend), which gives the folder tree. We could add another flag in CamelStore to over-ride the above option to fetch all folders while fetching the folders from contacts(EBookBackend)/calendar(ECalBackend) backends. I can help you with making these changes in imapx backend/CamelStore and inform you the changes which you would need to make in your account-setup plugin. Sounds ok? - Chenthill. Many greetings, Christian ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders
On Tue, 2010-07-20 at 12:41 +0200, Milan Crha wrote: On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? Hi, you said you want to use imapx internally, is it right? And even if only the imap provider itself, then I would suggest to subclass it (your base imap provider) in your evolution-kolab package and manage this within CamelStore::get_folder_info, by calling parent class' get_folder_info and then recreate folder information based on your needs (once with email folders only, once with calendar folders only, and so on). Just noticed the reply. I dont think it requires sub-classing as it seems to be applying for other collaborative backends such as groupwise where we would need to hide some folders iirc it was tasks/contacts (sorry forgot the exact folders), but remember discussing with Akhil. - Chenthill. Hope that helps, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders
Hi there, thanks Milan for your reply. On Tuesday 20 Juli 2010 Milan Crha wrote: On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? Hi, you said you want to use imapx internally, is it right? And even if IMAPX-only, yes. That's the master plan. :-) only the imap provider itself, then I would suggest to subclass it (your base imap provider) in your evolution-kolab package and manage this within CamelStore::get_folder_info, by calling parent class' get_folder_info and then recreate folder information based on your needs (once with email folders only, once with calendar folders only, and so on). Hm. Maybe I'm still missing some parts here on how Evolution internally works. Subclassing the Camel Provider in our backends and overloading get_folder_info() will work for the backend part, i.e. PIM data wich is accessed and managed from inside E-D-S. So far, no problem. But there is standard Email to handle as well, and if I understood correctly, Email handling is (presently) done inside Evolution, not E-D-S. Now, if I create a Kolab account, I will see not only the Email IMAP folders in Evolution (frontend, Email view), but *also* the parts of the IMAP tree for the Kolab server which hold PIM data. These are simply IMAP folders, just that they bear folder annotations. Other than that, the folders which hold PIM data (as single emails with XML attachments) are no different from true Email folders. This means, when I configure Evolution (2.30 let's say, without any Kolab plugin) as to access a Kolab server, nothing hinders Evolution to display the whole IMAP tree and the folders which hold PIM data just become visible as standard Email folders. This I cannot intercept from my backend code (or can I?), since Evolution just accesses the Kolab IMAP server without knowing that certain IMAP folders do not hold standard Emails which must not be accessible to the user. What's more, the IMAP folder layout in Kolab may change over time, as I create new address books, nesting things etc, so the folder tree is not static. Therefore, I cannot just pre-configure which folders to show and which ones to hide, I'll have to do this dynamically, solely relying on the folder annotations telling me which kind of IMAP folder I'm facing. For this to work, I would have to subclass the Camel Provider within my EPlugin - is that possible? So far, I have only seen EPlugins using existing Evolution infrastructure, but not changing the Camel Provider inside Evo... Hope that helps, Partly, yes. :-) Please feel free to correct me on any misconception I have regarding the internals of Evo/E-D-S, I'll be grateful for that. Also, if I need to be clearer on any Kolab issue, please let me know as well. Milan Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Couple new functions for ECal/EBook
On Tue, 2010-07-20 at 06:34 -0400, Matthew Barnes wrote: On Tue, 2010-07-20 at 11:21 +0530, chen wrote: Is it required ? Having it in ECalBackendStore simplifies the backend code to form the path based on the type (calendar,tasks,memos) at a single place rather than every backend doing it.. Forming the path at a single place instead of all the backends doing it is definitely the goal. My thought was just that ECalBackend can do it as easily as ECalBackendStore, since ECalBackendStore does nothing else with the URI + type it's given and the path still has to be shared with ECalBackendCache somehow. Moving it to ECalBackend seemed cleaner to me, but I can try to keep things as is if you'd prefer to avoid the API break. I am ok with having it in ECalBackend. Btw we could deprecate ECalBackendCache and update just ECalBackendStore. I thought of that, but evolution-mapi still uses ECalBackendCache pretty heavily. Should we give Bharath and Milan some time to migrate off it first? I hope they are doing it. Had a chat with Bharath a week back iirc as I realized just then that mapi was not migrated. It should take not more than half a day to migrate at the maximum. It should be more or less s/cache/store work :) - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Couple new functions for ECal/EBook
On Tue, 2010-07-20 at 11:21 +0530, chen wrote: On Mon, 2010-07-19 at 17:27 -0400, Matthew Barnes wrote: Backends using these classes can easily construct a suitable cache file or directory name from e_cal_backend_get_cache_dir(). get_cache_dir can simply return e_cal_backend_store_get_path. I just realized ECalBackend -- which is where the cache-dir property lives -- doesn't have access to ECalBackendStore. The derived backend classes all keep their own private store objects. So without an API break to make ECalBackendStore just take a filename, I'm back to square one. In lieu of an API break I think I'll have to just replicate the path building logic in ECalBackend, ECalBackendStore and ECalBackendCache. Not ideal, but still better than all the backends doing it themselves. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders
Hi there, On Tuesday 20 July 2010 chen wrote: On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: [...] Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? This cannot be done in a fool-proof way for IMAP as it does not provide information on the type of the folder. This can be done with an assumption that calendar folder will be named as 'calendar' or contact folders as 'contacts'. Not entirely correct, though. RFC 5464 - The IMAP METADATA Extension / imap- annotatemore specifies an extension to the IMAP protocol which does exactly that. The Kolab IMAP daemon uses this extension to differentiate between the folder types and Kontact does implement it - works quite well. Now, with our plugin, we strive to be en par with Kontact's features (or at least implement as much as possible) - let's see! :-) The other thought I get is, the contacts+calendar folder names can be collected as an option in account-setup and set as part of camel url (prolly through a kolab plugin, hiding it from the user. you can check how groupwise account set-up is implemented for an example) say hide_folders=list of folders with a separator. If the parameter is set, the folders can be hidden while fetching folder_info through camel_store_get_folder_info (in imapx backend), which gives the folder tree. Good idea. We'll have to check how to handle dynamic changes in the IMAP folder structure, still. Folders with annotations may come and go, nested or not - this is not static, and neither is the overall layout (other than a few static constraints), so we'll need to see how we can cope with that... We could add another flag in CamelStore to over-ride the above option to fetch all folders while fetching the folders from contacts(EBookBackend)/calendar(ECalBackend) backends. I can help you with making these changes in imapx backend/CamelStore and inform you the changes which you would need to make in your account-setup plugin. Sounds ok? We'll thankfully use whatever help we can get here. We also see clearly which problems arise in these areas because of our decision to settle on 2.30 ... this is the version we would need to change (branch is fine). It will be very much helpful to know which parts will be affected and how we should design our changes in order not to break anything. Thanks again for your help and for your awesome patience with us (this goes to the entire list). Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Fwd: Re: Couple new functions for ECal/EBook]
---BeginMessage--- Migration has been done and I'll submit the patch soon. Regards Punit On Tue, 2010-07-20 at 16:56 +0530, chen wrote: On Tue, 2010-07-20 at 06:34 -0400, Matthew Barnes wrote: On Tue, 2010-07-20 at 11:21 +0530, chen wrote: Is it required ? Having it in ECalBackendStore simplifies the backend code to form the path based on the type (calendar,tasks,memos) at a single place rather than every backend doing it.. Forming the path at a single place instead of all the backends doing it is definitely the goal. My thought was just that ECalBackend can do it as easily as ECalBackendStore, since ECalBackendStore does nothing else with the URI + type it's given and the path still has to be shared with ECalBackendCache somehow. Moving it to ECalBackend seemed cleaner to me, but I can try to keep things as is if you'd prefer to avoid the API break. I am ok with having it in ECalBackend. Btw we could deprecate ECalBackendCache and update just ECalBackendStore. I thought of that, but evolution-mapi still uses ECalBackendCache pretty heavily. Should we give Bharath and Milan some time to migrate off it first? I hope they are doing it. Had a chat with Bharath a week back iirc as I realized just then that mapi was not migrated. It should take not more than half a day to migrate at the maximum. It should be more or less s/cache/store work :) - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ---End Message--- ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders
On Tue, 2010-07-20 at 13:18 +0200, Christian Hilberg wrote: Hm. Maybe I'm still missing some parts here on how Evolution internally works. Subclassing the Camel Provider in our backends and overloading get_folder_info() will work for the backend part, i.e. PIM data wich is accessed and managed from inside E-D-S. So far, no problem. But there is standard Email to handle as well, and if I understood correctly, Email handling is (presently) done inside Evolution, not E-D-S. Hi, others will correct me, but from evolution-mapi point of view (which is, with evolution-exchange, closest to that what you are trying to do): - create a Camel provider, which, when placed to the right place, will be shown in new account creation as an account type (see camel-mapi-provider.c, there's everything needed for having new mail provider available in Evolution). Evolution-mapi is extending basic camel objects, like CamelStore, but as you want to use IMAPX, then less work for you, derive from it. Note that this Camel part has nothing to do with EPlugin, the most you define an EPlugin to add menu options on your folders, like Folder Size option for MAPI folders, but other than that the EPlugin part is optional for mailer part. - for calendar and addressbook support create your own EBookBackend/ECalBackend descendants (with defined all the virtual methods there). You need an EPlugin to have them accessible from UI, to be able to setup specific things on it. See exchange-mapi-account-setup.c:exchange_mapi_create_addressbook and exchange_mapi_create_calendar as examples. Note these are mentioned in org-gnome-exchange-mapi.eplug.xml. - evolution-mapi's EPlugin also listens for changes on EAccountList (which is a list of configured mail accounts) and adds/removes ESource-s for addressbooks/calendars based on enabled/disabled MAPI accounts, keeping these three in sync, so the only thing user needs to setup is an email account, and the addressbook/calendar are added automatically. With respect of folder structure changes, the first sync will update internal caches as necessary, namely camel-store-summary, allowing you to hold the necessary information about each folder, and also adding the type annotation on it too. How or when fetch that annotation is a question for you. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
