[Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
Although the Evolution developers have moved on to better things and consider Evolution 2.32 to be a dead end, there are distributions still trying to ship this dead end. It is the latest stable release of Evolution, after all. Rather than all the distributors working separately to keep track of patches and backport bug fixes from Evo HEAD, it would be useful if we could make a git tree somewhere which collects such patches and reduces our duplication of effort. Kind of like the -stable tree for the Linux kernel. To that end, I have created trees at: http://git.infradead.org/evolution-data-server-2.32.git git://git.infradead.org/evolution-data-server-2.32.git http://git.infradead.org/evolution-2.32.git git://git.infradead.org/evolution-2.32.git We can define our operating policy as we go, but I'd be happy if we could stick to *only* cherry-picking patches which have already been applied to the master branch (with massaging to make them apply as necessary). I've been using 'git cherry-pick -x' so that we can refer back to the original commit easily. I've backported a small number of fixes from HEAD that I think are appropriate, or which are already being shipped in some distributions. I'm more than happy to give accounts on git.infradead.org to distribution maintainers, and look at other patches which distributions are shipping. I hope that eventually, we might be permitted to use the real gnome-2-32 branch in GNOME git for this, rather than having to do it elsewhere. If that branch is a dead end and would otherwise be unused, then there's no harm in letting us use it as a more central location for our collaboration, surely? Presumably we'll do the same thing for Evolution 3.0 during the time period when it is orphaned by upstream, but still being shipped by distributions. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ 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] Maintenance fork for Evolution / EDS 2.32
On Fri, 2011-04-01 at 18:00 +0100, David Woodhouse wrote: I hope that eventually, we might be permitted to use the real gnome-2-32 branch in GNOME git for this, rather than having to do it elsewhere. If that branch is a dead end and would otherwise be unused, then there's no harm in letting us use it as a more central location for our collaboration, surely? I'm fine with you using the real gnome-2-32 branch. Would even be nice to see another formal 2.32 release if enough patches accumulate. Per GNOME's six-month release cycle, upstream maintainers have pretty much wrapped up 3.0 and are now focused on 3.1. ___ 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] Maintenance fork for Evolution / EDS 2.32
On Fri, 2011-04-01 at 13:28 -0400, Matthew Barnes wrote: On Fri, 2011-04-01 at 18:00 +0100, David Woodhouse wrote: I hope that eventually, we might be permitted to use the real gnome-2-32 branch in GNOME git for this, rather than having to do it elsewhere. If that branch is a dead end and would otherwise be unused, then there's no harm in letting us use it as a more central location for our collaboration, surely? I'm fine with you using the real gnome-2-32 branch. Would even be nice to see another formal 2.32 release if enough patches accumulate. That's great; thanks. I'll do a little more testing on the patches I've cherry-picked into my trees, and then unless someone else has objected in the meantime I'll push them. Per GNOME's six-month release cycle, upstream maintainers have pretty much wrapped up 3.0 and are now focused on 3.1. Although presumably there will be 3.01 and 3.02 releases so those branches aren't *quite* as orphaned as 2.32 yet :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ 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] Maintenance fork for Evolution / EDS 2.32
On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote: Although presumably there will be 3.01 and 3.02 releases so those branches aren't *quite* as orphaned as 2.32 yet :) Yeah, 3.0.1 at least per the GNOME schedule, although we've been doing at least one additional stable update ever since GNOME went from three down to just a single update per six-month cycle. ___ 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] RFC: camel-sasl try empty password first
I'm working on single-sign-on support for NTLM, where we don't actually
*know* the password, but just delegate the whole challenge/response
thing to a helper program.
That helper program is /usr/bin/ntlm_auth; the only current
implementation is the Samba one which works when you've logged into the
system using your Windows password and pam_winbind, but we're working on
a less baroque version that works {like,with} gnome-keyring, and there's
a simple hack at http://david.woodhou.se/ntlm_auth_v2.c for testing.
So I need a way to indicate that the authentication mechanism should be
tried once *without* a password, and then if that fails we should try
providing a password.
Thus the patch below. Anyone got a better suggestion for how to handle
it? A patch to actually use this facility in the NTLM authenticator will
follow, of course...
One alternative approach might be to to stop letting the authenticators
look at service-url-passwd, and instead have an 'authenticate' signal
on the CamelSasl object, much the same way as libsoup does it.
But then I think we'd still have to have the users know somehow if that
authenticate signal had been called on the first attempt, to know when
to set the CAMEL_SESSION_PASSWORD_REPROMPT flag, etc. I suspect it would
be a lot of extra work for something that doesn't really end up looking
any prettier by the time it's working.
Hence the 'try_empty_password' flag, which is relatively simple.
Comments?
commit b1787a5f85cdc1e46fb6ccf0c57134fc34f4e12e
Author: David Woodhouse david.woodho...@intel.com
Date: Fri Apr 1 23:25:05 2011 +0100
Add 'try_empty_password' flag to CamelServiceAuthType
NTLM will be use this, to support single-sign-on using /usr/bin/ntlm_auth
diff --git a/camel/camel-sasl-anonymous.c b/camel/camel-sasl-anonymous.c
index dbbb500..850b1ea 100644
--- a/camel/camel-sasl-anonymous.c
+++ b/camel/camel-sasl-anonymous.c
@@ -37,6 +37,7 @@ CamelServiceAuthType camel_sasl_anonymous_authtype = {
N_(This option will connect to the server using an anonymous login.),
ANONYMOUS,
+ FALSE,
FALSE
};
diff --git a/camel/camel-sasl-cram-md5.c b/camel/camel-sasl-cram-md5.c
index ae4bb16..54f9daa 100644
--- a/camel/camel-sasl-cram-md5.c
+++ b/camel/camel-sasl-cram-md5.c
@@ -48,6 +48,7 @@ CamelServiceAuthType camel_sasl_cram_md5_authtype = {
secure CRAM-MD5 password, if the server supports it.),
CRAM-MD5,
+ FALSE,
TRUE
};
diff --git a/camel/camel-sasl-digest-md5.c b/camel/camel-sasl-digest-md5.c
index ae12f7b..384f216 100644
--- a/camel/camel-sasl-digest-md5.c
+++ b/camel/camel-sasl-digest-md5.c
@@ -61,6 +61,7 @@ CamelServiceAuthType camel_sasl_digest_md5_authtype = {
secure DIGEST-MD5 password, if the server supports it.),
DIGEST-MD5,
+ FALSE,
TRUE
};
diff --git a/camel/camel-sasl-gssapi.c b/camel/camel-sasl-gssapi.c
index 61b3404..832c128 100644
--- a/camel/camel-sasl-gssapi.c
+++ b/camel/camel-sasl-gssapi.c
@@ -93,6 +93,7 @@ CamelServiceAuthType camel_sasl_gssapi_authtype = {
Kerberos 5 authentication.),
GSSAPI,
+ FALSE,
FALSE
};
diff --git a/camel/camel-sasl-login.c b/camel/camel-sasl-login.c
index de3aba4..465a8f7 100644
--- a/camel/camel-sasl-login.c
+++ b/camel/camel-sasl-login.c
@@ -42,6 +42,7 @@ CamelServiceAuthType camel_sasl_login_authtype = {
simple password.),
LOGIN,
+ FALSE,
TRUE
};
diff --git a/camel/camel-sasl-ntlm.c b/camel/camel-sasl-ntlm.c
index 6d2313a..a285214 100644
--- a/camel/camel-sasl-ntlm.c
+++ b/camel/camel-sasl-ntlm.c
@@ -44,6 +44,7 @@ CamelServiceAuthType camel_sasl_ntlm_authtype = {
NTLM / Secure Password Authentication.),
NTLM,
+ FALSE,
TRUE
};
diff --git a/camel/camel-sasl-plain.c b/camel/camel-sasl-plain.c
index e27a6b9..5b1845d 100644
--- a/camel/camel-sasl-plain.c
+++ b/camel/camel-sasl-plain.c
@@ -46,6 +46,7 @@ CamelServiceAuthType camel_sasl_plain_authtype = {
simple password.),
PLAIN,
+ FALSE,
TRUE
};
diff --git a/camel/camel-sasl-popb4smtp.c b/camel/camel-sasl-popb4smtp.c
index 043291b..00ef7ff 100644
--- a/camel/camel-sasl-popb4smtp.c
+++ b/camel/camel-sasl-popb4smtp.c
@@ -49,6 +49,7 @@ CamelServiceAuthType camel_sasl_popb4smtp_authtype = {
POPB4SMTP,
FALSE,
+ FALSE,
};
/* last time the pop was accessed (through the auth method anyway), *time_t */
diff --git a/camel/camel-service.h b/camel/camel-service.h
index d1efa89..35cf1a9 100644
--- a/camel/camel-service.h
+++ b/camel/camel-service.h
@@ -137,6 +137,7 @@ typedef struct {
const gchar *description;
const gchar *authproto;
+ gboolean try_empty_password;
gboolean need_password; /* needs a password to authenticate */
} CamelServiceAuthType;
diff --git a/camel/providers/imap/camel-imap-store.c
b/camel/providers/imap/camel-imap-store.c
index
Re: [Evolution-hackers] RFC: camel-sasl try empty password first
On Fri, 2011-04-01 at 23:46 +0100, David Woodhouse wrote: Thus the patch below. Anyone got a better suggestion for how to handle it? A patch to actually use this facility in the NTLM authenticator will follow, of course... One alternative approach might be to to stop letting the authenticators look at service-url-passwd, and instead have an 'authenticate' signal on the CamelSasl object, much the same way as libsoup does it. But then I think we'd still have to have the users know somehow if that authenticate signal had been called on the first attempt, to know when to set the CAMEL_SESSION_PASSWORD_REPROMPT flag, etc. I suspect it would be a lot of extra work for something that doesn't really end up looking any prettier by the time it's working. Hence the 'try_empty_password' flag, which is relatively simple. I think the flags approach is fine. Long as you're breaking ABI (which is perfectly okay right now), you might consider combining the 'try_empty_password' and 'needs_password' booleans into a single CamelServiceAuthFlags enum to future-proof the ABI a little. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
