[Kde-pim] Re: [PATCH] Repacing libntlm
gyurco at freemail.hu
Tue Nov 2 14:09:16 GMT 2004
Waldo Bastian wrote:
>>I was suggesting using KNTLM for the NTLM support, so that it can support
>>NTLM out of the box.
>>NTLM is very, very, very common in corperate environments, and I think it
>>is something KMail should support without a thrid party liibrary if it is
>>possible using a library that will already be in kdelibs.
> I fail to see the advantage of duplicating effort in KDE cvs if there already
> exists a maintained solution outside KDE cvs.
> I do see disadvantages in the form of extra maintenance and security updates.
> A good example of that could recently be seen with the KWord PDF-import
> filter which had a private copy of xpdf and which we almost missed when xpdf
> got a ton of security updates. And then there was the private copy of libtiff
> in kfax that hadn't seen any of the fixes and security updates that went in
> the maintained version of libtiff for a few years.
I wrote the libkntlm because libntlm (which is a seperate, non-KDE lib):
- Doesn't support 'true' unicode usernames and passwords.
- Doesn't support NTLMv2.
- It has a bit 'strange' buffer handling, which I don't know if it's
perfectly safe or not (however it's not too hard to review the code).
Also libkntlm is simple enough. KNTLM class' implementation is some
hundred lines of code, with NTLMv2 support (without DES and MD4). It's
not a big effort.
Unfortunatly SASL-aware protocols cannot use this class (without big
hacks in them), since they're using the cyrus-sasl library, which has
its own implementation. Another solution would be to use cyrus' own NTLM
implementation in protocols like http, which should make libntlm and
libkntlm obsolete in KDE.
More information about the kde-core-devel