RE: Linux port
Xenitellis S <[email protected]> Sat, 24 Jun 2000 15:13:53 +0100
| Newsgroups | gmane.ietf.pfl |
|---|---|
| Message-ID | <[email protected]> |
In the recent LinuxExpo 2000 at London, I asked the IBM spokesman about this issue, the lack of a Linux port of Jonah, since Jonah is "freeware". He was evangelical about Linux and the audience was very happy about the success story of OS/390 running Linux. IBM has managed to show the good profitability of Linux. The reply for the Jonah issue was that he was not aware of it, and he asked me to send him a personal e-mail on the issue. Should I send one? simos p.s. other things missing for a linux port are the (free?) crypto libraries. There was an e-mail of a person that supossedly wrote a CSP using openssl as a base. He sent the e-mail to this list from a free e-mail service. Any e-mail sent to him went without reply. Intel promished to supply a Linux port of CDSA 2.0 in September. (src: intel.com) Bull is supposed to be working on a CDSA 2.0 port (src: bull.fr). They have a VPN product out using it. I do not know if they only use their crypto accelerator for the cryptography needs. It remains to be seen if that port is more or less the one to be released. Bull looks Linux-friendly and this is nice news. > > > >2)Will there be a linux port for Jonah (implementing CDSA ver 2.0) soon > >and when will it be? > > I am no longer with Iris, so I can not officially speak for > Iris/Lotus/IBM, > but I do not believe they > are going to dedicate the resources to port Jonah to CDSA 2.0. But they > would probably not > mind (and would probably encourage ) someone else to doing it. Having not > looked into CDSA 2.0 > at all I have no idea how difficult the task would be. There is also no > guarantee that the move to > CDSA 2.0 would make Jonah instantly port to Linux. The use of the STL is > not only in the core CDSA > component, but in some of the providers that were written for Jonah. So > these providers would need > to be ported to CDSA 2.0 and possibly re-written to not use the STL (or > find a STL that GCC likes, which > would probably be a more useful exercise). >