to follow up on my previous posting:
- gnutls does not provide the HMAC functions, which are needed for MPPE,
hence I will rule that out for now
- matrixssl seems to have a very odd licence, with the split between
commercial and non-commerical use...
- openwrt already provides support for openvpn, which in turn uses
openssl so why is there a need to switch to matrixssl ?
conclusion: for now, I won't be bothered to migrate my patch from
openssl to gnutls or matrixssl any time soon. Others are most welcome to
try , of course, and I am willing to test any patches that others provide.
share and enjoy,
JJK
Jan Just Keijser wrote:
The patch is based on OpenSSL basically because I have used openssl in
the past and have come to know it a bit; I don't see any reason why
MatrixSSL (which I do not know) or libgnutls (which I know a little
but have had problems with in the past) could not be used. The EAP-TLS
patch uses an SSL TLSv1 context and not much more than that, so I
can't think of a reason why any other package which provides the same
functionality could not be used.
I will give libgnutls a shot over the next few days/weeks, and perhaps
MatrixSSL as well.
share and enjoy,
JJK
Marco d'Itri wrote:
On Jul 25, James Cameron <james.cameron@xxxxxx> wrote:
You've used OpenSSL, which has a license that is not altogether open,
specifically clause 6 which requires acknowledgement. Is there any
reason why you couldn't use MatrixSSL?
I would hate to see EAP-TLS depend on a niche license.
I do not think I would enable EAP-TLS in the Debian package in this case
since it would require pulling the MatrixSSL package in the base system.
If you do not like the advertisement clause in the OpenSSL license there
is libgnutls which is LGPL'ed and widely used (and has a sane API...).
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
