Hi Peter: Perhaps, it would be useful to you if I clarify the host and target environments.
The host is an i686 machine with the Lenny release of Debian Linux. The target is a M5249 Coldfire machine without an MMU or disk. Compilation is done on the host with GNU ELF Tool chain. It is used to compile and link all of UC Linux and applications to be run on the target, and has UC Linux in source code form. Ultimately the host creates an S.19 file containing UC Linux an all the applications, and the S.19 file is downloaded to the target. The target contains no compilers of development infrastructure. Best Regards, Paul R. ********** PREVIOUS MESSAGE ***** Hi Peter: I forgot to mention that the version of libgnutls that came with GSASL provides Diffie-Hellman. Best Regards, Paul R. ************ PREVIOUS MESSAGE ********** Hi Peter: First, thank you for the quick and detailed reply and be assured the difference between SSH and SASL is clear to me. Also, I must emphasize that my interest is in the SSH-2 component subset required to support SFTP rather than SSH. I think the SASL version of libgcrypt meets the minimum libssh2 requirements, and that AES and RIJNDAEL are the same. Also, I assume that libssh2 can use DES and 3DES interchangeably. It appears most SFTP implementations also use the following: Diffie Hellman-SHA1, Blowfish, Twofish, HMAC-SHA1 and HMAC-MD5. Do you think that is correct ? The reason I mentioned SASL is the version GSASL I am using came with a version of libgcrypt. However, I am not sure if libgcrypt is part of the GSASL package or it came from elsewhere. In any case, assuming a version of libgcrypt that supplies what libssh2 needs is found, libssh2 and libgcrypt can easily be linked together. Is that correct ? Using OpenSSL is not an option because it is too large for an embedded environment. You seem to suggest that compiling libssh2 requires modern automake capabilities. Using a newer version of the GNU ELF Toolchain may solve that problem for me--cross compilers etc. But, migrating to a newer UC Linux version is not an option. Would this be a barrier to using libssh2 ? (i.e. I am sure the GNU toolchain I am using does not have modern automake capabilities.) Note that the UC Linux Makefile scheme, and where and how libraries are linked is quite different than in standard Linux. In addition there are differences in how forking and exits work despite the fact the kernel API is the same. Most of the "porting" I mentioned consists of creating Makefiles that fit within the UC Linux scheme which is not a huge effort but certainly not trivial. Knowing libssh2 had been ported to the UC Linux environment or that is known to be easy to port it would make it much easier to assess the risk and time involved in using libssh2. Finally, do you have a size estimate for libssh2, assuming it is configured for SFTP support in my target environment ? Best Regards, Paul R. Peter Stuge wrote: > Hi Paul, > > Paul Romero wrote: > > libssh2 > .. > > Has it previously been ported to the UC Linux OS ? > > No porting is required. You may know that uClinux provides the exact > same API as the regular Linux kernel. > > > Note that UC Linux is a diskless embedded system OS, > > Um, no, uClinux is a kernel variant.. > > > and typically runs on processors without an MMU. Also, the .o file > > format is ELF 32-bit MSB relocatable 68020, not stripped. > > That will obviously depend on which binary file formats you enable in > the uClinux configuration, and which architecture you are running on. > > > My target system is M5249C3 dev. board with UC Linux version 2.4.27 > > and version 2.4.X or the kernel. > > Maybe this is what you got delivered to you but I highly doubt that > this would be the only configuration that you could use with that > board. I would suggest that you create a fresh set of binaries for > your target, from the latest versions of what makes up a typical > embedded Linux system. > > > It must be compiled with version 2.95.3 of the GNU ELF Toolchain > > I also doubt this very strongly. The 2.4 codebase might indeed have > some requirements on compiler version, but I don't think that 2.95.3 > is the only thing you can use. Note also that 2.95.3 is the version > of GCC only. "Toolchain" is a term commonly used to describe C > compiler (GCC) along with linker and other binary utilities (GNU > binutils). binutils has it's own versioning scheme. > > > which does not have modern automake capabilities. > > Again I doubt this. You could most likely use the very latest > autotools also with the older toolchain that you got. > > > I use the SASL library > .. > > I wonder if the libssh2 SH-2 library duplicates a significant part > > of functionality. > > No. libssh2 implements SSH, not SASL. libssh2 specifically does not > implement cryptography, for that it uses libgcrypt or OpenSSL. I > don't think the SASL library implements cryptography either. > > > The size of the current SASL authentication/encryption library I am > > using is about 605.4 K, and it provides GNU TLS functionality. > > If there's a libgcrypt API then libssh2 can use it. > > > The other functionality it provides is as follows: DES, MD5, ARC4, > > DSA, BLOWFISH, TWOFISH, CAST5, MD2, MD4, RSA, SHA1, SHA265, SHA512, > > RIJNDAEL, SERPENT, TIGER, X.509, ANS1, HMAC-MD5, DIGEST-MD5. The > > largest components are DEs, RSA and ASN1 whose sizes are about 18.3, > > 9.1, and 67 K respectively. > > The minimum you need for libssh2 is AES, RSA, DSA and SHA1. > > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: [email protected] _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
