similar to: [PATCH] Solaris 10 and missing OpenSSL functions >128bit

Hi, the following patch to cipher.c enables OpenSSH 3.9.1 to compile on IRIX 5.3 with the native IDO cc: --- cipher.c.orig 2004-10-17 12:04:10.000000000 +0200 +++ cipher.c 2004-10-17 13:43:22.000000000 +0200 @@ -76,15 +76,15 @@ u_int key_len; const EVP_CIPHER *(*evptype)(void); } ciphers[] = { - { "none", SSH_CIPHER_NONE, 8, 0,

Hello, I'm having trouble recompiling openssh 3.7p1 on an old RedHat (6.1). OpenSSL Version is on this system is "openssl-0.9.5a-1". ./configure --sysconfdir=/etc/ssh --with-pam make [...] make cipher-aes.o gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\"

http://bugzilla.mindrot.org/show_bug.cgi?id=675 Summary: cipher.c error when building against openssl 0.9.5a on Mandrake 7.2 Product: Portable OpenSSH Version: 3.7.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo:

I am trying to upgrade my ssh to 3.7p1 on a Solaris 8 Enterprise 450 server. I receive the following errors: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/ssl/inc lude -I/usr/local/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/u sr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass \"

Hi, The 20130110 snapshot fails to build against OpenSSL 0.9.8 and 1.0.0 with the following error: gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -fno-builtin-memset -fstack-protector-all -I. -I. -DSSHDIR=\"/tmp/foo/etc\" -D_PATH_SSH_PROGRAM=\"/tmp/foo/bin/ssh\"

http://bugzilla.mindrot.org/show_bug.cgi?id=704 Summary: 3.7.1p1 does not compile on FreeBSD 4.2 Product: Portable OpenSSH Version: 3.7.1p1 Platform: All OS/Version: FreeBSD Status: NEW Severity: critical Priority: P2 Component: Build system AssignedTo: openssh-bugs at mindrot.org

When compiling the software it breaks with an error on the cipher.c file. Lot's of warnings and error of undeclared stuff. Snippet follows: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/ssl/include -Iyes -I/usr/local/include -DSSHDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\"

On 2016-11-02, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > If the standard way works, I am happy to include the original patch I > sent, amended so that it checks for presence of LIBRESSL_VERSION_NUMBER. > If they keep this promise, then we should have no worries about things > breaking up. Diff below is what I've added to OpenBSD ports. The libressl API is not cast in

Hi all, As I reported earlier (with a typo in the work [BUG]) client certification validation *does not* work even if you do everything exactly according to all documentation and attempts at helpful advice. I have seen this issue with both startssl.com and self-signed certificates, and based on what I've seen from searching the web, this is a problem that has gotten little attention because

Skipped content of type multipart/alternative-------------- next part -------------- --- ssl-proxy-openssl.c.orig 2006-04-04 10:32:58.000000000 +0200 +++ ssl-proxy-openssl.c 2006-06-01 09:24:57.000000000 +0200 @@ -498,7 +498,7 @@ const char *ssl_proxy_get_peer_name(struct ssl_proxy *proxy) { X509 *x509; - char buf[1024]; + char buf[256]; const char *name; if

---------- Forwarded message ---------- Date: Fri, 18 Jan 2013 10:19:35 +1100 (EST) From: Damien Miller <djm at mindrot.org> To: Iain Morgan <Iain.Morgan at nasa.gov> Subject: Re: Inconsisten declaration of ssh_aes_ctr_iv() On Thu, 17 Jan 2013, Iain Morgan wrote: > > Could you tell me the declaration of the function pointer do_cipher in > > OpenSSL's evp.h on your

On Fri, 12 Oct 2018, Jakub Jelen wrote: > Something like this can be used to properly initialize new OpenSSL > versions: > > @@ -70,12 +70,19 @@ ssh_compatible_openssl(long headerver, long libver) > void > ssh_OpenSSL_add_all_algorithms(void) > { > +#if OPENSSL_VERSION_NUMBER < 0x10100000L > OpenSSL_add_all_algorithms(); > > /* Enable use of crypto

# HG changeset patch # User David Hicks <david at hicks.id.au> # Date 1373085976 -36000 # Sat Jul 06 14:46:16 2013 +1000 # Node ID ccd83f38e4b484ae18f69ea08631eefcaf6a4a4e # Parent 1fbac590b9d4dc05d81247515477bfe6192c262c login-common: Add support for ECDH/ECDHE cipher suites ECDH temporary key parameter selection must be performed during OpenSSL context initialisation before ECDH and

>openssl version Libressl 2.4.4 Patch for dovecot: perl -i -ple 's/^(#if OPENSSL_VERSION_NUMBER < 0x10100000L\s*)$/$1 || defined (LIBRESSL_VERSION_NUMBER)/' ./src/lib-dcrypt/dcrypt-openssl.c; perl -i -ple 's/^(#if OPENSSL_VERSION_NUMBER < 0x10100000L\s*)$/$1 || defined (LIBRESSL_VERSION_NUMBER)/' ./src/lib-ssl-iostream/dovecot-openssl-common.c; perl -i -ple 's/^(#if

Hello All, After seeing what is probably the zillionth "OpenSSL headers don't match library" bug report I made the following mod to configure.ac. It always writes the versions of the library and headers to config.log and prints them to stdout if they don't match. Hopefully this will help diagnose these problems in future. Example output below. -Daz. $ ./configure [snip]

After doing some testing by myself, I noticed that libressl, for some unknown reason, defines #define OPENSSL_VERSION_NUMBER 0x20000000L No idea why they decided to advertise that they are OpenSSL v2.0.0. A local fix, if you need one, is to use #if OPENSSL_VERSION_NUMBER == 0x20000000L #define OPENSSL_VERSION_NUMBER 0x1000100L #endif in dcrypt-openssl.c after includes. Aki On

It does work today, I am just bit worried that it will keep on breaking with libressl as they evolve their API. I would personally like to avoid more ifdef hell if possible... Aki On 02.11.2016 13:22, Michael A. Peters wrote: > Standard way to fix it (on the LibreSSL page) is to check for > LIBRESSL_VERSION_NUMBER - e.g. the patch attached which I think > catches them all where

If the standard way works, I am happy to include the original patch I sent, amended so that it checks for presence of LIBRESSL_VERSION_NUMBER. If they keep this promise, then we should have no worries about things breaking up. Aki On 02.11.2016 14:24, Michael A. Peters wrote: > Indeed, which is why I use it. > > But it also is in the minority which is why I find it acceptable for

IMHO it would be acceptable to have a LibreSSL patch that is maintained by the people who want it. It's free software, and that kind of is the point of Open Source. On 11/02/2016 04:36 AM, Michael A. Peters wrote: > They have stated they are going to remain API compatible with 1.0.1h (or > g, forget which they forked) - their new stuff is outside of libcrypto. > > On 11/02/2016

Indeed, which is why I use it. But it also is in the minority which is why I find it acceptable for FLOSS projects like dovecot to elect to only un-officially support LibreSSL via a community maintained patch. One of the reasons why OpenSSL was forked is because they were trying to support so many platforms that it made the code a real mess. Don't want the same to happen to another