Re: [PEAR-QA] Re: Maintenance of Auth_SASL PEAR package

Hi,

2011/8/23 Christian Weiske <[email protected]>:
>> > The next steps will be the following:
>> > - I move the Auth_SASL package from svn to github
>> > - After that, you can fork it and apply your patches
>> > - Send your patches/pull requests to the pear-dev/pear-qa and we'll
>> >  have a look at them. If nobody answers, bug us and ask again.

Ok so I made a patch for the SCRAM (RFC-5802) support.
This is a full support of the "normal" SCRAM-* mechanisms without
channel binding (so not yet the SCRAM-*-PLUS mechanisms).

I hooked this to the hash extension (enabled by default since PHP
5.1.2, a PECL extension for older PHP versions) but fallbacking to
sha1 and md5 functions and a custom hmac otherwise.
As a consequence, if the hash extension is available, it shall support
SCRAM-MD5, SCRAM-SHA-1, SCRAM-SHA-224, SCRAM-SHA-256, SCRAM-SHA-384
and SCRAM-SHA-512. Otherwise it will support "only" SCRAM-SHA-1 and
SCRAM-MD5.

I have also made a few naming improvements. The Auth_SASL factory
(SASL.php) was accepting names like DIGESTMD5 or CRAMMD5. But they are
not the official names (see the IANA registry:
http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xml).
In other words, it was impossible to use this factory in order to
directly test and process a mechanism received during a SASL
negotiation (for instance while connecting a XMPP, IMAP or POP server)
and one had to keep a correspondance table between official SASL
naming and this "custom" naming. Now the SASL names can be tried
directly with their real name received on the wire.
I still accept the custom naming too of course (the goal is not to
break existing code!) but added a E_USER_DEPRECATED warning when a
user pass such broken names as parameter.

>> > - After some good patches, you'll get full maintainer status.

I hope this one will make it then! I have skimmed through the coding
standards and hope I don't break too many rules. I saw the line length
is not a strict rule for instance (I set 120 characters as my default
vim configuration, and sometimes I even allow myself a little more if
I think this will be nicer), so I hope that's not too big a problem.
Don't hesitate to tell me though if there are some rules I should be
stricter on myself about!

I will have a few other features or fix of interest in the near future, I think.

Oh and my SCRAM implementation is working and tested against a live
XMPP server authentication (which worked perfectly).
Thanks!

Jehan