Subject: Re: libssh2: Ported to UC Linux ? + DETAIL +MORE

Re: libssh2: Ported to UC Linux ? + DETAIL +MORE

From: Paul Romero <paulr_at_rcom-software.com>
Date: Thu, 01 Jul 2010 23:45:09 -0700

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: paulr_at_rcom-software.com
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-07-02