Suggestions regarding Authen-SASL & libnet
jue...@jherz.redirectme.net
using an program that incorporates the above libs, I experienced some
problems with them.
The program uses Authen-SASL 2.03 which seems "a bit old", but all in
all I still think the changes would also do 2.10 good.
1. Net::POP3
In auth () I don't like
my $mechanisms = $capa->{SASL} || 'CRAM-MD5';
If a server doesn't contain a SASL line I guess that has a reason. So
I'd not pretend he's wrong and still try CRAM-MD5.
Writing
my $mechanisms = $capa->{SASL};
return () unless $mechanisms;
instead would still work the same for users but save the try.
2. Authen::SASL::Perl
In 2.03 there was no DIGEST-MD5 and no GSSAPI, so Authen just exited
badly if the server only supported one of thos, which is fatal. Though
by supporting more algorithms the problem is mitigated in newer
versions, I'd still like seeing it not to croak.
What about replacing
or croak "No SASL mechanism found\n";
by
or return (); #No SASL mechanism found
in client_new ()?
auth () in Net::POP3 would need a
return () unless $client;
added between
my $client = $sasl->client_new('pop3',${*$self}{'net_pop3_host'},0);
and
my $str = $client->client_start;
and I guess
also initial () in Authen::SASL needs to get adjusted.
But that would prevent some program using the lib to get terminated.
Regards,
Jürgen
Achim Grolms
> my $mechanisms = $capa->{SASL};
> return () unless $mechanisms;
> instead would still work the same for users but save the try.
Graham says:
"The reason it tries CRAM-MD5 i because there were servers
out there that would accept it but did not publish it in capa. If
there server does not support it then it will return an error when
you try."
The change you suggest breaks interoperability to servers of that kind.
If the user want to check the servers capability he can use
exists $capa->{'SASL'} as described in
<http://perl.grolmsnet.de/authensasl/> and terminate to avoid the try.
> auth () in Net::POP3 would need a
> return () unless $client;
> added between
> my $client = $sasl->client_new('pop3',${*$self}{'net_pop3_host'},0);
What version of Net::POP3 have you used?
The actual version in repository is available at
<http://svn.goingon.net/repos/libnet/trunk/Net/POP3.pm>
(hopefully becoming 2.29, I hope Graham will bring it to CPAN).
Are you willing to discuss Net::POP3 based on that version?
Thank you,
Achim
jue...@jherz.redirectme.net
thank you for answering.
> Graham says:
> "The reason it tries CRAM-MD5 i because there were servers
> out there that would accept it but did not publish it in capa. If
> there server does not support it then it will return an error when
> you try."
> The change you suggest breaks interoperability to servers of that kind.
Ok, I reckoned with that argument. I'd say if their SASL support isn't
recognized, it's their own fault. In contrast I've seen servers which
disconnect if confronted with mechanisms they don't know.
> If the user want to check the servers capability he can use
> exists $capa->{'SASL'} as described in
> <http://perl.grolmsnet.de/authensasl/> and terminate to avoid the try.
That's a workaround I could live with. Have to try that.
>> auth () in Net::POP3 would need a
>> return () unless $client;
>> added between
>> my $client = $sasl->client_new('pop3',${*$self}{'net_pop3_host'},0);
>
> What version of Net::POP3 have you used?
That was 2.28.
> The actual version in repository is available at
> <http://svn.goingon.net/repos/libnet/trunk/Net/POP3.pm>
> (hopefully becoming 2.29, I hope Graham will bring it to CPAN).
I've looked into that version. While the current code is good readable,
the changes in 2.28_2 are quite a mess for a Perl newbie like me.
But could it be this new code already sorts out mechanisms not supported
by Authen::SASL before trying?
Thanks,
Jürgen
Achim Grolms
> Ok, I reckoned with that argument. I'd say if their SASL support isn't
> recognized, it's their own fault.
Sure.
Graham's point is - a change in behaviour will break existing code
that relies on Net::POP3 and that behaviour.
My point is: There is no "own fault". Remember John Postels "law": "be
conservative in what you do, be liberal in what you accept from others."
> In contrast I've seen servers which
> disconnect if confronted with mechanisms they don't know.
That's no problem if that servers announce the mechisms they support.
The "CRAM-MD5 fallback try" is only triggerered as a last try if the server
does not announce SASL-support by CAPA or AUTH command.
Do you know a POP3 server out there that matches this criterion?
But as a programmer you always can use the capa() method to check
if the server announces SASL to avoid the CRAM-MD5 fallback.
[...]
> > The actual version in repository is available at
> > <http://svn.goingon.net/repos/libnet/trunk/Net/POP3.pm>
> > (hopefully becoming 2.29, I hope Graham will bring it to CPAN).
>
> I've looked into that version. While the current code is good readable,
> the changes in 2.28_2 are quite a mess for a Perl newbie like me.
It was hard to write, it should be hard to read.
What part in detail is the problem?
> But could it be this new code already sorts out mechanisms not supported
> by Authen::SASL before trying?
The 2.28_2 implemention
1. uses CAPA/AUTH to detect the serverside mechnisms
2. checks if one of that mechnisms match the supported mechanisms of the
clientside Authen::SASL object.
One of the the mechanisms of intersection of serverside and clientside
mechanisms is choosed and used for authentication. (Fail if intersection is
empty).
Achim
jue...@jherz.redirectme.net
> Graham's point is - a change in behaviour will break existing code
> that relies on Net::POP3 and that behaviour.
> My point is: There is no "own fault". Remember John Postels "law": "be
> conservative in what you do, be liberal in what you accept from others."
Sigh, I must repeat myself: I reckoned with that argument. ;)
While I'd see this the other way around: accepting in this case is the
list of capabilities (no SASL algorithms) and doing is what you try
(sending out AUTH CRAM-MD5 without the server announcing support). And
the other question is: what are standards are good for then?
>> In contrast I've seen servers which
>> disconnect if confronted with mechanisms they don't know.
>
> That's no problem if that servers announce the mechisms they support.
Sure, but I meant such not that advertise SASL that crash or otherwise
disconnect when receiving AUTH CRAM-MD5.
> Do you know a POP3 server out there that matches this criterion?
I've seen several of them in the last two years, but I didn't write down
their names.
What I can live with is asking the server the old way via "AUTH". Since
this is implemented in 2.28_2 I really don't see a reason for ||
'CRAM-MD5' anymore.
> But as a programmer you always can use the capa() method to check
> if the server announces SASL to avoid the CRAM-MD5 fallback.
Yep, I tested this and it works. Unfortunatelly it results in two CAPA's
sent out. Wouldn't it be better if in auth() $self->capabilities would
be used?
>> > The actual version in repository is available at
>> > <http://svn.goingon.net/repos/libnet/trunk/Net/POP3.pm>
>> > (hopefully becoming 2.29, I hope Graham will bring it to CPAN).
>>
>> I've looked into that version. While the current code is good readable,
>> the changes in 2.28_2 are quite a mess for a Perl newbie like me.
>
> It was hard to write, it should be hard to read.
> What part in detail is the problem?
No special part. It's when statements get interleaved like
my %user_mech; @user_mech{@user_mech} = ();
or
my @mech = @user_mech ? grep { exists $user_mech{$_} } @server_mech :
@server_mech;
And that not only one time here or there but several succeeding. But as
I wrote, it must be me since I'm not trained to this.
> 2. checks if one of that mechnisms match the supported mechanisms of the
> clientside Authen::SASL object.
> One of the the mechanisms of intersection of serverside and clientside
> mechanisms is choosed and used for authentication. (Fail if intersection is
> empty).
The question is, how it fails. In 2.28_2 $sasl->client_new() survives
instead croaking. Must have something to do with passing 'pop' instead
of 'pop3' when calling from auth(), but I don't understand why.
Anyways the result is the same I wanted to achieve, but I had to tweak
Authen::SASL's client_new().
Jürgen
Achim Grolms
> Achim Grolms wrote:
> > 2. checks if one of that mechnisms match the supported mechanisms of the
> > clientside Authen::SASL object.
> > One of the the mechanisms of intersection of serverside and clientside
> > mechanisms is choosed and used for authentication. (Fail if intersection
> > is empty).
>
> The question is, how it fails. In 2.28_2 $sasl->client_new() survives
> instead croaking. Must have something to do with passing 'pop' instead
> of 'pop3' when calling from auth(), but I don't understand why.
'pop3' was changed to 'pop' because in mechanism 'GSSAPI' the servicename
is part of the underlying Kerberos service principal.
<http://www.iana.org/assignments/gssapi-service-names>
defines the list of correct servicenames.
Achim