[JDEV] Re: SASL, deployment and coding
rob at cataclysm.cx
Tue Feb 4 18:11:40 CST 2003
> I'll read that as: Use the one built in the standered, not SASL as it is
> not in any clients. So I ask, Anyone know how to interface with SASL
> password files? I am guessing they are based on Unix Password Files.
If you're using Cyrus, you could call "saslpasswd", which would work. Of
course, if the administrator reconfigures Cyrus to use some other data
source, this won't work.
> <message to='receve-id' from='send-id'>
> fexable - Accept this code
> hard line - elements not in correct order, dump line.
By elements do you mean attributes? It does not matter what order
attributes appear in XML, they all have the same semantic meaning.
> >For backwards compatibility reasons, its not possible to enforce the use
> >of SASL (and I doubt it ever will be). For guaranteed end-to-end
> >security, its necessary to encrypt individual packets using GPG (or
> Well, not for everyone, but all server and clients that support SASL
> must use it with a minimum level of encription. And then make sure that
> EVERYONE starts including SASL. It is very easy to include IFF (if
> and only if) you use the cyrus SASL code relesed by Carnegie Mellon
One of SASL's strengths is that the administrator can configure it for
their environment. IMO, an implementation shouldn't limit the mechanisms
that can be used, or the configuration for those mechanisms (although it
could certainly make recommendations ie by having a secure default
configuration). That's the great thing about the Cyrus SASL library - I
don't need to care how its been set up.
If you want to pursue this further, I do strongly suggest raising it on
the XMPP list - its the only place where anything can come from it.
Robert Norris GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the JDev