Re: [Evolution-hackers] Moving EExtension to libedataserver
On Fri, 2011-09-09 at 22:18 -0400, Matthew Barnes wrote: I got this working today. Would anyone object if I create the gnome-3-2 branch early next week so I can commit this for 3.3.1 and then rebase my account-mgmt branch on it? Hi, I wouldn't do that, as it doubles work for translators, because it's their time now. Does it make that large difference to wait for next two weeks? You can always do those things locally and branchcommit later anyway. 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
[Evolution-hackers] CVE-2011-3201 Issue in evolution
Hi All,
I just came across the bug
https://bugzilla.redhat.com/show_bug.cgi?id=733504 , CVE-2011-3201
evolution: mailto: attachment parameter can lead to accidental data
exfiltration.
Going ahead with the blacklist approach in
https://bugzilla.redhat.com/show_bug.cgi?id=733504#c8, I am attaching a
basic patch.
Kindly provide your opinion about the solution and files to be
blacklisted.
I have following list of files to be blacklisted:
/etc/passwd, /etc/cipe/options, /etc/exports, /etc/gshadow,
/etc/hosts.allow, /etc/hosts.deny, /etc/hosts.equiv,
/etc/ipsec.secrets, /etc/lilo.conf, /etc/ppp/chap-secrets,
/etc/ppp/pap-secrets, /etc/samba/smbpasswd, /etc/securetty,
/etc/security/access.conf, /etc/shadow, /etc/slip/slip.passwd,
/etc/smbpasswd, /etc/snmp/snmpd.conf, /etc/ssh/shosts.equiv,
/etc/ssh, /etc/sudoers, /etc/tripwire, /etc/vpnd/mysecret.key,
/etc/vpnd/vpnd.lcl.key, /etc/vpnd/, /etc/vtund.conf,
.ICEauthority, .Xauthority, .aim/AIM.cfg, .cvspass,
.fetchmailrc, .gaimrc, .gpg/, .gnome_private/, .gnupg/,
.micqrc, .ncftp/firewall, .nessus.keys, .netrc,
.pgp/secring.pgp, .pgp/, .rhosts, .shosts,
.silc/private_key.prv, .ssh, .vmware, .vnc/passwd, .xchat/,
/root/.ICEauthority, /root/.Xauthority, /root/.aim/AIM.cfg,
/root/.cvspass, /root/.fetchmailrc, /root/.gaimrc, /root/.gpg/,
/root/.gnome_private/, /root/.gnupg/,/root/.micqrc,
/root/.ncftp/firewall, /root/.nessus.keys, /root/.netrc,
/root/.pgp/, /root/.rhosts, /root/.shosts,
/root/.silc/private_key.prv, /root/.ssh, /root/.vmware/,
/root/.vnc/passwd, /root/.xchat/serverlist.conf,
/root/.xchat/servers.conf, /var/log/secure*, ., ..
diff --git a/composer/e-msg-composer.c b/composer/e-msg-composer.c
index 22245ea..2939b6a 100644
--- a/composer/e-msg-composer.c
+++ b/composer/e-msg-composer.c
@@ -3998,6 +3998,34 @@ merge_always_cc_and_bcc (EComposerHeaderTable *table,
merge_cc_bcc (addrv, bcc, to, *cc, *bcc);
e_destination_freev (addrv);
}
+static const gchar *blacklisted_files [] = {/etc/passwd,
/etc/cipe/options, /etc/exports, /etc/gshadow, /etc/hosts.allow,
/etc/hosts.deny,
+ /etc/hosts.equiv,
/etc/ipsec.secrets, /etc/lilo.conf, /etc/ppp/chap-secrets,
+ /etc/ppp/pap-secrets,
/etc/samba/smbpasswd, /etc/securetty, /etc/security/access.conf,
+ /etc/shadow,
/etc/slip/slip.passwd, /etc/smbpasswd, /etc/snmp/snmpd.conf,
/etc/ssh/shosts.equiv,
+ /etc/ssh, /etc/sudoers,
/etc/tripwire, /etc/vpnd/mysecret.key, /etc/vpnd/vpnd.lcl.key,
/etc/vpnd/,
+ /etc/vtund.conf,
.ICEauthority, .Xauthority, .aim/AIM.cfg, .cvspass, .fetchmailrc,
.gaimrc,
+ .gpg/, .gnome_private/,
.gnupg/, .micqrc, .ncftp/firewall, .nessus.keys, .netrc,
+ .pgp/secring.pgp, .pgp/,
.rhosts, .shosts, .silc/private_key.prv, .ssh,
+ .vmware, .vnc/passwd,
.xchat/, /root/.ICEauthority, /root/.Xauthority, /root/.aim/AIM.cfg,
+ /root/.cvspass,
/root/.fetchmailrc, /root/.gaimrc, /root/.gpg/, /root/.gnome_private/,
/root/.gnupg/,
+ /root/.micqrc,
/root/.ncftp/firewall, /root/.nessus.keys, /root/.netrc, /root/.pgp/,
/root/.rhosts,
+ /root/.shosts,
/root/.silc/private_key.prv, /root/.ssh, /root/.vmware/,
/root/.vnc/passwd,
+ /root/.xchat/serverlist.conf,
/root/.xchat/servers.conf, /var/log/secure*, ., ..};
+
+gboolean check_blacklisted_file (gchar *filename)
+{
+ gboolean blacklisted = FALSE;
+ gint i,len;
+
+ for(i = 0; !blacklisted i G_N_ELEMENTS(blacklisted_files); i++)
+ {
+ len = strlen(blacklisted_files[i]);
+ if(g_strstr_len(filename, len, blacklisted_files[i]))
+ blacklisted = TRUE;
+ }
+
+ return blacklisted;
+}
static void
handle_mailto (EMsgComposer *composer,
@@ -4090,8 +4118,17 @@ handle_mailto (EMsgComposer *composer,
} else if (!g_ascii_strcasecmp (header, attach) ||
!g_ascii_strcasecmp (header, attachment)) {
EAttachment *attachment;
+ gboolean check = FALSE;
+ GError *error = NULL;
camel_url_decode (content);
+ check = check_blacklisted_file(content);
+ if(check)
+ {
+ g_warning(Blacklisted File);
+ g_set_error(error, CAMEL_ERROR,
CAMEL_ERROR_GENERIC,
+
Re: [Evolution-hackers] Moving EExtension to libedataserver
Hi all, Am Montag 12 September 2011, um 09:57:26 schrieb Milan Crha: On Fri, 2011-09-09 at 22:18 -0400, Matthew Barnes wrote: I got this working today. Would anyone object if I create the gnome-3-2 branch early next week so I can commit this for 3.3.1 and then rebase my account-mgmt branch on it? Hi, I wouldn't do that, as it doubles work for translators, because it's their time now. Does it make that large difference to wait for next two weeks? You can always do those things locally and branchcommit later anyway. Bye, Milan Regarding the current plannings for porting evolution-kolab to a current dev version of Evo/E-D-S, it could prove very helpful to have this infrastructure available for basing our work on. We'd appreciate it much if the merge could be done as soon as the translator's window is closed and the merge can be done without foreseeable extra work for the release currently under preparation. Kind regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 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] Moving EExtension to libedataserver
Hi there, just one bit of nitpicking: Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: [...] The EExtension framework was introduced in Evolution 2.30 as part of the Shouldn't that read 2.32? At least, the wiki page says so. Kind regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 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] Moving EExtension to libedataserver
Hi again, Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: [...] The API is already fully documented and our wiki has usage instructions for it: http://live.gnome.org/Evolution/Extensions Is the list of EExtensible-tagged classes listed at the end of the wiki page up-to-date (and exhaustive) for the current dev version of Evo/E-D-S? I had a glance at the page since I'm trying to figure out whether or not the account setup stuff we're currently doing via EPlugin in evolution-kolab could instead be based on EExtensions (bearing in mind that EPlugin is going away sooner or later anyway). What's more, there are some Evolution UI extensions which we would like to implement for evolution-kolab, and since some of them are Kolab-specific, it seemed a better way to do it as an EExtension, rather than trying to hack Evolution directly. The questions at hand now are, do you see EExtension fit as an EPlugin replacement for account setup already, and can UI extensions (like additional entries in context menus or functional extensions of UI dialogs) already be done via EExtensions? Kind regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 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] Moving EExtension to libedataserver
Hi, I hope I've got the reference right... Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: [...] I'm going to need EExtension for the new D-Bus service I talked about recently [1] anyway, so it makes sense to get this part merged early. Kind regards, Christian [1] http://mail.gnome.org/archives/evolution-hackers/2011-August/msg00025.html -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 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] Evo/E-D-S security (libs) long-term plans
Hi all. During the initial implementation of the evolution-kolab plugin, we were concerned with using hardware crypto devices (TPM, trusted platform module) as a means to store and retrieve client certificates for securing TLS connections to a Kolab server (by configuring the Kolab server to require certificates for client authentication). We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS. These are protocols handled by Camel and the underlying NSS library. In order to access the crypto token, we needed to supply a token PIN, which we were not able to pass from Evo to E-D-S in version 2.30 as live data (pass-and- forget). So we had to use a fake implementation: we store the user PIN along the rest of the account data and reading it in the backend via ESource. Clearly, this violates security (and we are saying to in our user manual), but it demonstrates that in principle, things are working. To get this thing right, we would need a means to ask for a security pin from within the backend, presenting a dialog to the user (not necessariy via Evo, maybe the new ESources and account management stuff Matt is working on could help with that). We've succeeded here _only_ since Camel uses the Mozilla NSS lib for securing connections. However, there is one protocol, for which we failed to implement any demonstrator for client-certificate-based authentication using a hardware crypto device: LDAPS. The implementation in Evo uses the OpenLDAP lib as a protocol implementation, which in turn uses GnuTLS for security (version 2.1x 2.12 at that time). The combination of OpenLDAP and GnuTLS did not allow us to get things flying regarding the use of hardware crypto devices via the PKCS #11 interface. Where NSS only needs a token PIN and figures out either automatically or via external configuration files which of the possibly multiple client certificates to use, GnuTLS needs an URI which fully determines exactly which location inside the token to read the client certificate from, no automatisms here. While this allows for the application to control which cert to use (and not relying on any automatism, which may or may not work as needed), it requires the application to do it. Now, if on top of GnuTLS sits some protocol library like OpenLDAP, which rightfully denies to be bothered with security details of the underlying transport lib, we've got a problem: we must break the strict top-down layer approach and configure GnuTLS first, then use the protocol lib like OpenLDAP. We would have needed to hack around this directly in Evo to solve this, which clearly was (and probably is) out-of-scope for the evolution-kolab project. My question now is, how are the plans for Evo and E-D-S to handle these things, mid-term and long-term? Are there plans to favor any single one security lib, or will there be a multitude of different libs be used? GnuTLS is sort of home-made, while NSS is alien but works for the issue described above (which, admittedly, is a little esoteric, but *maybe* symptomatic?). In GnuTLS, I've seen much progress with PKCS #11 (like the integration of p11- kit), but it requires more details to be handled by the application itself. I'm looking forward to reading your input, Kind regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 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] Further thoughts on ESources
Hi all, Am Donnerstag 25 August 2011, um 18:46:15 schrieb Matthew Barnes: [...] Proposal: I think the key file management needs to be centralized in a new D-Bus service, tentatively called e-source-registry. The ESourceRegistry singleton class in client programs would then be a proxy for the D-Bus service. So we'd have a bit of a D-Bus hierarchy: evolution and other e-d-s clients e-addressbook-factory | e-calendar-factory \ | / e-source-registry Are there plans for any sort of live service implemented by this (or yet another component), so that e.g. a backend implementation can query for user input when it needs it? The use case I have in mind originates from the problem we are facing in evolution-kolab backend processes, that we cannot ask for a security PIN (which should not be stored anywhere, but be used-and-forgotten) when opening a security hardware device for a session. If you see Evolution as any one of possibly multiple clients to E-D-S, then it probably makes no sense to pop-up any *Evo* dialogue to ask for the PIN. This would make Evo an even more privileged E-D-S client than it currently is, while my understanding of the current development seems to be to rid Evo of it's privileged status and turn it more into a yet-another E-D-S client. For the problem at hand, we would most probably need some dumb input dialog to pop up, requesting the token PIN, and be gone again - the way security tokens should be used mandates their PIN not be stored *anywhere*, not even in a gnome-keyring or services like that... so I'm curious which plans may exist here (or may need thought-smithing ;-). Kind regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 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] CVE-2011-3201 Issue in evolution
On Mon, 2011-09-12 at 00:40 -0600, Vibha Yadav wrote: I have following list of files to be blacklisted: I know we discussed this already, but just to clarify for others: the blacklist only applies to attach parameters in mailto: URLs. You can still attach any file manually in the composer window. I think instead of the blacklist consisting entirely of individual file names, which we'll constantly have to amend, you can eliminate most of these and be pretty darn future-proof by applying the following rules: - No hidden files (e.g. .foo). - No files in hidden directories (e.g. .secret/foo). - No files under /etc. - No files with .. as a path component. That leaves only a few individual files in the blacklist, which we can amend as needed. When eliminating a file attachment in a mailto: URL, print a message to the terminal stating so -- suspicious attachment $FILENAME was removed for security -- or something thereabouts. ___ 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] Moving EExtension to libedataserver
On Mon, 2011-09-12 at 10:49 +0200, Christian Hilberg wrote: Am Montag 12 September 2011, um 09:57:26 schrieb Milan Crha: I wouldn't do that, as it doubles work for translators, because it's their time now. Does it make that large difference to wait for next two weeks? You can always do those things locally and branchcommit later anyway. Regarding the current plannings for porting evolution-kolab to a current dev version of Evo/E-D-S, it could prove very helpful to have this infrastructure available for basing our work on. We'd appreciate it much if the merge could be done as soon as the translator's window is closed and the merge can be done without foreseeable extra work for the release currently under preparation. Very well, we'll branch then when the hard code freeze begins as we usually do. The code freeze begins next Monday (September 19) after 2.91.92 tarballs are released. ___ 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] Moving EExtension to libedataserver
On Mon, 2011-09-12 at 11:11 +0200, Christian Hilberg wrote: Is the list of EExtensible-tagged classes listed at the end of the wiki page up-to-date (and exhaustive) for the current dev version of Evo/E-D-S? Until 3.3.1 development begins, the extensible list only applies to Evolution. I'll give the list a refresh today, but you can also just grep the source code: git grep -l E_TYPE_EXTENSIBLE Classes are made extensible as-needed, and it's trivial to do so. I had a glance at the page since I'm trying to figure out whether or not the account setup stuff we're currently doing via EPlugin in evolution-kolab could instead be based on EExtensions (bearing in mind that EPlugin is going away sooner or later anyway). I think for now it's easier to go the EPlugin route and I'll help convert it when the time comes. I already have frameworks in place on my account-mgmt branch to convert all address book and calendar setup EPlugins to EExtensions (this reduces our reliance on EConfig, which I also intend to kill over the long-term). Mail account setup uses CamelProvider data structures with configuration details instead of EPlugins, which has its own share of problems but will likely survive a little longer. What's more, there are some Evolution UI extensions which we would like to implement for evolution-kolab, and since some of them are Kolab-specific, it seemed a better way to do it as an EExtension, rather than trying to hack Evolution directly. The questions at hand now are, do you see EExtension fit as an EPlugin replacement for account setup already, and can UI extensions (like additional entries in context menus or functional extensions of UI dialogs) already be done via EExtensions? It depends. One of the reasons I'm dismantling EPlugin is to discourage the tacking on of arbitrary features, because what you tend to get with that approach is an application that feels like it has a bunch of arbitrary features tacked on, rather than thoughtfully designed in. Another reason I'm dismantling EPlugin is that a lot of our existing plugins can be classified into natural extension points such as account configuration, importers, inline attachment display, etc. These types of plugins would be better served as extensions of a more formal API, which EExtensible and EExtension allows you to define. Before adding something to the user interface that you think is Kolab-specific, check whether the other groupware modules (Exchange, GroupWise, etc.) do something similar. If so, perhaps we can generalize what you and other groupware modules are trying to do and build a formal and extensible API for it directly into Evolution or E-D-S. It will have to be considered case-by-case. There probably are cases which are truly Kolab-specific, but I want you to have to invent as few wheels as possible. To answer your second question, menus and dialogs _can_ be extended via EConfig without relying on XML files, but it's a little more cumbersome. See the startup-wizard module in Evolution for an example: http://git.gnome.org/browse/evolution/tree/modules/startup-wizard/evolution-startup-wizard.c#n430 ___ 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] Further thoughts on ESources
On Mon, 2011-09-12 at 13:30 +0200, Christian Hilberg wrote: Am Donnerstag 25 August 2011, um 18:46:15 schrieb Matthew Barnes: evolution and other e-d-s clients e-addressbook-factory | e-calendar-factory \ | / e-source-registry Are there plans for any sort of live service implemented by this (or yet another component), so that e.g. a backend implementation can query for user input when it needs it? Yes, in fact the more I think about the problem the more I'm convinced that this new low-level D-Bus service should handle user authentication prompts in a manner similar to PolicyKit user prompts. (In other words, PolicyKit handles user prompts itself and doesn't force each and every PolicyKit client to deal with it -- so we can mimic its solution for address book and calendar authentication.) The use case I have in mind originates from the problem we are facing in evolution-kolab backend processes, that we cannot ask for a security PIN (which should not be stored anywhere, but be used-and-forgotten) when opening a security hardware device for a session. If you see Evolution as any one of possibly multiple clients to E-D-S, then it probably makes no sense to pop-up any *Evo* dialogue to ask for the PIN. This would make Evo an even more privileged E-D-S client than it currently is, while my understanding of the current development seems to be to rid Evo of it's privileged status and turn it more into a yet-another E-D-S client. For the problem at hand, we would most probably need some dumb input dialog to pop up, requesting the token PIN, and be gone again - the way security tokens should be used mandates their PIN not be stored *anywhere*, not even in a gnome-keyring or services like that... so I'm curious which plans may exist here (or may need thought-smithing ;-). I mentioned earlier that with E-D-S moving to EExtension, the D-Bus services can now be extended for purposes other than simply registering new backend types. Perhaps this is a use case. I'm woefully ignorant about most security APIs and the issues they try to address. I can help with the nuts and bolts details, but for more conceptual questions (such as those raised in your security post), I'd recommend consulting with and possibly bringing into the discussion Stef Walter -- the gnome-keyring author -- who is more aware of the state of NSS vs. Gnutls and has been helping to add security support to GNOME libraries. He might even have a ready-made solution to your token issue in one of his libraries. ___ 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] Evo/E-D-S security (libs) long-term plans
On Mon, 2011-09-12 at 13:16 +0200, Christian Hilberg wrote: We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS. These are protocols handled by Camel and the underlying NSS library. In order to access the crypto token, we needed to supply a token PIN, which we were not able to pass from Evo to E-D-S in version 2.30 as live data (pass-and- forget). So we had to use a fake implementation: we store the user PIN along the rest of the account data and reading it in the backend via ESource. Clearly, this violates security (and we are saying to in our user manual), but it demonstrates that in principle, things are working. To get this thing right, we would need a means to ask for a security pin from within the backend, presenting a dialog to the user Hi, with the current eds (upcoming 3.2.0) you can pass parameters via ECredentials, same as you do with e_passwords_ask_password, thus yes, this is doable from book/cal backends now too. However, there is one protocol, for which we failed to implement any demonstrator for client-certificate-based authentication using a hardware crypto device: LDAPS. The implementation in Evo uses the OpenLDAP lib as a protocol implementation, which in turn uses GnuTLS for security (version 2.1x 2.12 at that time). The OpenLDAP 2.12 is kinda old. And if I recall correctly, they moved to NSS as well, at least 2.4.23 seems to use NSS based on their changelog. Thus, I would say, when you move to current eds, then you can be pretty sure that the used OpenLDAP will be the one with NSS. Or you can add a dependency to evolution-kolab on the OpenLDAP which fits you best. 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
Re: [Evolution-hackers] Moving EExtension to libedataserver
On Mon, 2011-09-12 at 09:27 -0400, Matthew Barnes wrote: On Mon, 2011-09-12 at 10:49 +0200, Christian Hilberg wrote: Am Montag 12 September 2011, um 09:57:26 schrieb Milan Crha: I wouldn't do that, as it doubles work for translators, because it's their time now. Does it make that large difference to wait for next two weeks? You can always do those things locally and branchcommit later anyway. Regarding the current plannings for porting evolution-kolab to a current dev version of Evo/E-D-S, it could prove very helpful to have this infrastructure available for basing our work on. We'd appreciate it much if the merge could be done as soon as the translator's window is closed and the merge can be done without foreseeable extra work for the release currently under preparation. Very well, we'll branch then when the hard code freeze begins as we usually do. The code freeze begins next Monday (September 19) after 2.91.92 tarballs are released. Hi, it's 3.1.92, but anyway, it's hard-code freeze and still time for translators. I never much liked the early branching, as I know how pity it is to commit one change twice. Would it really make that big difference to wait one more week (it's those two, as I mentioned in my first mail here)? 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
