similar to: [Bug 1437] New: OpenSSL engine support not enabled

I am confused on how ssh_SSLeay_add_all_algorithms() get used in the ssh applications for openssh-5.7p1 and later releases. I don't see any of the applications making calls to ssh_SSLeay_add_all_algorithms(). There is a macro that redefines SSLeay_add_all_algorithms() to ssh_SSLeay_add_all_algorithms() but I don't see any code calling SSLeay_add_all_algorithms(). In openssh-5.6p1 and

https://bugzilla.mindrot.org/show_bug.cgi?id=1882 Summary: Since 5.7p1 OpenSSH doesn't take advantage of OpenSSL hardware engine Product: Portable OpenSSH Version: 5.7p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo:

Ok, I think I've figured that out. I used 6.7 stable and it was wrong. Now I took 6.8 from master and configure --without-openssl went fine. But now when make I see ... openbsd-compat//libopenbsd-compat.a(xcrypt.o): In function `xcrypt': /cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83: undefined reference to `crypt'

Hello, I am looking into the ssh sources. I couldn't get docs for SSLeay_add_all_algorithms. I tried for this in openssl.org. Can someone give some pointers for documents, which can tell how to use the SSL functions used in the ssh sources and what they do?? thanks kapil

Hi all, attached is a patch that enables using hardware crypto accelerators available through OpenSSL library for SSH operations. Especially in ssh/sshd it can bring a significant speed improvement. OTOH if no crypto engine is available, nothing bad happens and default software crypto routines are used. This patch is used in SUSE Linux OpenSSH package and proved to work (at least it didn't

I made some quick changes to support the IA security thing in Uniware 7.1.1. I wish I understood all of this well enough to make a proper patch to include new defines and what not. I tried and made a mess. Hopefully I can get a better grasp this weekend. The only files I changed were xcrypt.c and Makefile. Makefile needed -lcrypt and -liaf added to LIBS=. It had -lcrypto but needed -lcrypt for

https://bugzilla.mindrot.org/show_bug.cgi?id=1440 Summary: OpenSSL engine support should be enabled by default Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: Build system AssignedTo:

Hi all. While on the subject of the OpenSSL interface, this patch optionally enables OpenSSL's ENGINE support at build time. Apply to a snapshot, autoreconf and "./configure --with-ssl-engine". Testing (esp. with a real hardware engine) would be appreciated. Index: INSTALL =================================================================== RCS file:

Hi, I am trying to install tinc-1.0pre8 on my RH 9.0 (kernel 2.4.20-13.9) system. I have already installed Openssl (v0.9.7a). When i try to run the ./configure script, it stops at the follwing check ---SNIP-- checking openssl/pem.h presence... yes checking for openssl/pem.h... yes checking for SHA1_version in -lcrypto... yes checking for RAND_pseudo_bytes... yes checking for

Hi there, I have tried compiling OpenSSH 4.3p2 using the following steps: Upgrade OpenSSL tar xvfz openssl-0.9.8a.tar.gz cd openssl-0.9.8a ./config make make install Upgrade zlib tar xvfz zlib-1.2.3.tar.gz ./configure make test make install Upgrade OpenSSH tar xvfz openssh-4.3p2.tar.gz cd openssh-4.3p2.tar.gz ./configure --with-tcp-wrappers --with-ssl-dir=/usr/local/ssl

Hi, I just installed OpenSSH 3.3p1 on a SunOS 4.1.4 system (actually a 3-year old Auspex file server) as a replacement for an older, probably vulnerable ssh version. I used gcc, openssl 0.9.6d, zlib 1.1.4 and the configure incantation ./configure --with-tcp-wrappers --with-privsep-user=privsep (the latter option obviously being the default value). There were two problems: (a) memmove seems

Darren Tucker wrote: > Question is: what to do? > c) make packet_disconnect a real function. I say c. //Peter

I read the exchange regarding > 8 char passwords on Unixware from the end of June. Is anything being done to add support for >8 character passwords on SCO OSR6 (in udk mode)? I have it working by calling osr5bigcrypt(), instead of bigcrypt(), in openbsd-compat/xcrypt.c and linking with -lcrypt. libcrypt has bigcrypt(), but for whatever reason, openssh built with it fails to authenticate

The init functions are not longer required in OpenSSL 1.1 so I dropped them. TLSv1_client_method() should not be used because it enables only the TLSv1.0 protocol. Better is to use SSLv23_client_method() which enable all the protocols including TLSv1.2. With this functions SSLv2 and SSLv3 is theoretically possible but as of today those protocols are usually build-time disabled. To avoid all this

On Wed, Jan 16, 2013 at 12:04:52PM -0500, Stephen Checkoway wrote: > > On Jan 16, 2013, at 10:07 AM, Brad Smith <brad at comstyle.com> wrote: > > > I was wondering if someone with more familiarity with MC > > on X86 could consider looking into adding support for > > the hyphenated versions of the VIA Padlock instructions? > > > Take a look at

Hi, I'm using tinc for ~ 2 years now and I'm very happy with it (thanks to the makers - this is very good program to use). Anyway everytime I build I have this odd problem and until now I always found a way to solve it but now I'm really stuck. I'm trying to build tinc-pre7 and I always reach to this error on configure: --------------------- checking for RAND_pseudo_bytes... no

On Jan 16, 2013, at 10:07 AM, Brad Smith <brad at comstyle.com> wrote: > I was wondering if someone with more familiarity with MC > on X86 could consider looking into adding support for > the hyphenated versions of the VIA Padlock instructions? Take a look at llvm/lib/Target/X86InstrSystem.td perhaps. -- Stephen Checkoway

I was wondering if someone with more familiarity with MC on X86 could consider looking into adding support for the hyphenated versions of the VIA Padlock instructions? If anyone is up for it there are details within these two bug reports.. http://www.llvm.org/bugs/show_bug.cgi?id=8556 http://www.llvm.org/bugs/show_bug.cgi?id=10266 -- This message has been scanned for viruses and dangerous

Hi All. I noticed that xcrypt.c now has some variable declarations after code within a block (for some sets of #ifdef's). Won't that choke some compilers? Should it do something like the attached? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually

If nobody objects within 24 hours, I will tag and release 2.4.2-pre1. cheers, Arnaud