Make it build using OpenSSL 1.1.0 #48

kroeckx · 2016-09-18T17:59:16Z

No description provided.

Jakuje · 2016-10-21T14:01:33Z

sshkey.c

 		break;
 	case KEY_RSA_CERT:
+#if 0


This is intentionally left out or like todo for future readers?

I've added the message I sent to the openssh-unix list about this. Does that clear things up?

Thank you. I noticed your message on the mailing list, but forgot to check it properly before commenting. Adding it here clears that up. Thank you.

kroeckx · 2016-10-21T16:57:11Z

It has the same regression tests failures as the master branch, and it has been tested with both 1.0.2 and 1.1.0.

Some comments about the patch:

I've included an libcrypto-compat.c to add new functions from OpenSSL that are needed with 1.1.0 but didn't exist in 1.0.2. Since they are copied from the OpenSSL source code, I also added the OpenSSL license to it. If this is a problem we can probably agree to put that file under a different license.
I've replaced the 2 EVP_CipherInit() calls in cipher_init() with 1. OpenSSL now clears everything when you call EVP_CipherInit() again, so what was passed in the first but not in the second call, and what the function calls between them did, was lost.
The test suite was insisting that things like rsa->n where not NULL in sshkey/test_sshkey.c. sshkey_add_private was also doing something like that for the private parts. I don't agree that it should just have BN members that are not set to a real value. So I removed that code and the checks. I'm not even sure why this was done. But sshkey_add_private() ends up as a rather useless function now.
In sshkey_private_deserialize() there was a KEY_RSA_CERT case. I'm not sure what it's about and I guess the test suite also doesn't check it. But it seems that it only has the private key in that case and OpenSSL now seems to insist that an RSA needs to have the public key information too.

Jakuje · 2016-10-27T08:04:37Z

sshkey.c

+
+			if (p == NULL || q == NULL || g == NULL ||
+			    pub_key == NULL ||
+			    (ret = sshbuf_put_bignum2(cert, p)) != 0 ||


This is certainly wrong. In this case, you should not allocate&put&set. It should be get&put. The same for below RSA case.

You're right, new commit added.

Jakuje · 2016-11-02T09:56:17Z

I noticed you didn't port the SSH1 code to OpenSSL 1.1.0 -- we don't care about this protocol, but in clients it will be among us for some time. I added a the missing (only client side) bits in the answer on the mailing list [1].

Also I noticed you created a new compat filename, even though, there is already openbsd-compat/openssl-compat.{c,h}, which should be able to accommodate these changes, though the final decisions is probably up to the upstream developers which place to choose.

Also the missing part under #if 0, which is using zero BIGNUMs for missing parts.

[1] http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035454.html

noloader · 2017-04-02T21:06:43Z

Please expedite this patch. Lack of OpenSSL 1.1.0 support is harming users. From OpenSSL 1.1.0 integrtion on the user mailing list:

The OpenSSL 1.0.2 downgrade means users lose a number of features from OpenSSL, like Poly1305, curve25519 and the project's improved security posture and testing procedures. (Other improvements are available at https://www.openssl.org/news/openssl-1.1.0-notes.html).

cookiengineer · 2017-04-09T08:28:16Z

@Jakuje @kroeckx What is the work that is left to be done in order to get this PR merged? Following this thread it's a bit unclear for me as a third-party guy.

Jakuje · 2017-04-09T20:24:17Z

@cookiengineer The most of the discussion about this topic was held on the mailing list thread linked from the previous comment. The bottom-line can be found here:

http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035497.html

There is no work need to be done on this PR (ok, there are few problems in this PR resolved by the patch carried in Fedora) or upstream, but some compatibility between OpenSSL releases was requested which is very unclear if it can realistically happen.

The proposed openssl 1.1 patches are here: openssh/openssh-portable#48 Openssl maintainers are not in a hurry to get 1.1 support in; if it doesn't show up within reasonable time, we can take a patch from Fedora: http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035454.html Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>

The proposed openssl 1.1 patches are here: openssh/openssh-portable#48 Openssl maintainers are not in a hurry to get 1.1 support in; if it doesn't show up within reasonable time, we can take a patch from Fedora: http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035454.html (From OE-Core rev: 66a6ef9bf0d368cea6fb0df7d23c49c1f66667a1) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The proposed openssl 1.1 patches are here: openssh/openssh-portable#48 Openssl maintainers are not in a hurry to get 1.1 support in; if it doesn't show up within reasonable time, we can take a patch from Fedora: http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035454.html Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>

The proposed openssl 1.1 patches are here: openssh/openssh-portable#48 Openssl maintainers are not in a hurry to get 1.1 support in; if it doesn't show up within reasonable time, we can take a patch from Fedora: http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035454.html (From OE-Core rev: 5ccf4a9786fc607a5838edb3bf409f83d7483ba6) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

davidben

Someone pointed this patch out to me as something Debian was considering picking up? A few drive-by comments:

davidben · 2017-10-16T19:54:15Z

dh.c

-		DH_free(dh);
-		return NULL;
-	}
+	BIGNUM *p, *g;


This should be NULL-initialized otherwise some of the goto err paths below will get confused on malloc error.

davidben · 2017-10-16T19:55:58Z

dh.c

+	    (g = BN_new()) == NULL)
+		goto err;
+	if (BN_hex2bn(&p, modulus) == 0 ||
+	    BN_hex2bn(&g, gen) == 0 ||


Nit: I believe you can just omit lines 294 and 295 (after fixing the NULL-initializing above). BN_hex2bn just allocates things for you.

davidben · 2017-10-16T19:58:10Z

cipher.c

@@ -372,7 +372,7 @@ cipher_init(struct sshcipher_ctx **ccp, const struct sshcipher *cipher,
 		ret = SSH_ERR_ALLOC_FAIL;
 		goto out;
 	}
-	if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,
+	if (EVP_CipherInit(cc->evp, type, (u_char *)key, (u_char *)iv,


Asking EVP_CipherInit to copy keylen bytes worth of key before telling it what keylen is (EVP_CIPHER_CTX_set_key_length) seems kind of questionable, notably for ciphers with variable-length keys. Are you sure this works? It was probably previously in two steps so it'd all happen in the right order.

I can't even remember why I did change (it's been more than a year). But I guess the same applies to the IV?

Oh, I did make a comment about this:

I've replaced the 2 EVP_CipherInit() calls in cipher_init() with 1. OpenSSL now clears everything when you call EVP_CipherInit() again, so what was passed in the first but not in the second call, and what the function calls between them did, was lost.

I wonder if this is actually a problem in OpenSSL.

I think the IV can be passed in at either time? OpenSSL doesn't have a mechanism for ciphers with variable-length IVs as far as I know.

If the EVP_CIPHER has a fixed length key [and you already took care that what you're passing as the right size, since the EVP_CipherInit API isn't bounds-checked], you don't need to do EVP_CIPHER_CTX_set_key_length first. If you have a variable-length key cipher [and you're not using whatever the default key size is], you do.

Granted, it seems the only such ciphers, barring ENGINE mischief, are Blowfish, CAST, RC2, RC4, and RC5 so this pattern is only of so much interest... :-) Though the existing EVP_CIPHER_CTX_set_key_length logic did also act as a bounds check I think.
https://git.openssl.org/gitweb/?p=openssl.git&a=search&h=HEAD&st=grep&s=EVP_CIPH_VARIABLE_LENGTH
https://git.openssl.org/gitweb/?p=openssl.git&a=search&h=HEAD&st=grep&s=EVP_CIPH_CUSTOM_KEY_LENGTH

Aha! I think what might actually be going on here is that openssh should have been using EVP_CipherInit_ex, not EVP_CipherInit. EVP_CipherInit was for folks who didn't call EVP_CIPHER_CTX_init (which EVP_CIPHER_CTX_new did implicitly).

But in 1.0.2, there was this weird quirk where EVP_CipherInit would skip EVP_CIPHER_CTX_init if cipher was NULL:
https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/evp_enc.c;h=be577bac767fe9cf2c163be6967b20d1f6cc9014;hb=refs/heads/OpenSSL_1_0_2-stable#l94

OpenSSL 1.1.0 lost this behavior:
https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/evp_enc.c;h=d21a0c7e54d54a5a77a2d5a6593e4851cf2f5291;hb=HEAD#l50

So I believe you want to revert this and merely switch those EVP_CipherInit calls to EVP_CipherInit_ex, which should work fine in 1.0.2 and 1.1.0. (Unless 1.1.0 additionally changed behavior here in ways I'm missing.) You may also wish to consider at minimum marking EVP_CipherInit as deprecated and documenting this behavior change, and possibly restoring the 1.0.2 behavior to avoid breaking folks.

davidben · 2017-10-16T20:12:51Z

digest-openssl.c

-	if (EVP_DigestInit_ex(&ret->mdctx, digest->mdfunc(), NULL) != 1) {
+	ret->mdctx = EVP_MD_CTX_new();
+	if (ret->mdctx == NULL ||
+	    EVP_DigestInit_ex(ret->mdctx, digest->mdfunc(), NULL) != 1) {
 		free(ret);


This now leaks ret->mdctx if EVP_DigestInit_ex hits a malloc failure. You want EVP_MD_CTX_free(ret->mdctx); free(ret); or ssh_digest_free(ret).

davidben · 2017-10-16T20:19:11Z

libcrypto-compat.c

@@ -0,0 +1,410 @@
+/*


(Personally I would have just made these header-only, but whatever.)

davidben · 2017-10-16T20:32:37Z

ssh-keygen.c

-		buffer_get_bignum_bits(b, key->dsa->q);
-		buffer_get_bignum_bits(b, key->dsa->pub_key);
-		buffer_get_bignum_bits(b, key->dsa->priv_key);
+	case KEY_DSA: {


Nit: These blocks seem over-indented (which makes the diff a little more annoying), or is that the preferred style here? Ditto with the other case FOO: { ... } blocks.

davidben · 2017-10-16T20:38:46Z

ssh-pkcs11.c

@@ -67,7 +67,7 @@ struct pkcs11_key {
 	struct pkcs11_provider	*provider;
 	CK_ULONG		slotidx;
 	int			(*orig_finish)(RSA *rsa);
-	RSA_METHOD		rsa_method;
+	RSA_METHOD		*rsa_method;


pkcs11_rsa_finish doesn't free this.

davidben · 2017-10-16T20:40:13Z

ssh-pkcs11.c

 				    attribs[2].ulValueLen, NULL);
+				if (RSA_set0_key(rsa, rsa_n, rsa_e, NULL) == 0)


Check that rsa_n and rsa_e are NULL.

davidben · 2017-10-16T20:40:27Z

ssh-pkcs11-client.c

-	helper_rsa.rsa_priv_enc = pkcs11_rsa_private_encrypt;
-	RSA_set_method(rsa, &helper_rsa);
+	if (helper_rsa == NULL) {
+		helper_rsa = RSA_meth_dup(RSA_get_default_method());


Error-handling?

davidben · 2017-10-16T20:41:17Z

sshkey.c

 	switch (k->type) {
 #ifdef WITH_OPENSSL
 	case KEY_RSA1:
 	case KEY_RSA:
 	case KEY_RSA_CERT:
-		return BN_num_bits(k->rsa->n);
+		RSA_get0_key(k->rsa, &bn, NULL, NULL);
+		return BN_num_bits(bn);


RSA_bits? (Also DSA_bits below, but you'll need to add a new compat wrapper.)

kroeckx · 2017-10-29T18:31:08Z

I've fixed the merge conflicts, rebased it against current master, and fixed various issues.

Jakuje · 2017-11-14T11:52:45Z

ssh-pkcs11.c

 			    == NULL) {
 				error("RSAPublicKey_dup");
 			}
 			if (x509)
 				X509_free(x509);
 		}
-		if (rsa && rsa->n && rsa->e &&
+		RSA_get0_key(rsa, &n, &e, NULL);


This needs to be rewritten to something like the following, otherwise it will segfault for non-RSA keys (ECC on yubikey):

if (rsa && RSA_get0_key(rsa, &n, &e, NULL) && n && e &&

I just noticed it with the version I run on Fedora.

nope ... the RSA_get0_key() is void function so it will not work this way. But clearly we can call this function only if we are sure the rsa is not NULL.

the RSA_get0_key() is void function so it will not work this way. But clearly we can call this function only if we are sure the rsa is not NULL

Just my 2¢, but if RSA_get0_key can't handle a NULL parameter, then it sounds like an OpenSSL bug. The RSA_get0_key document does not state the parameter cannot be NULL; and it also states other parameters can be NULL.

rcombs · 2017-12-01T03:31:59Z

Anything still blocking here, other than the RSA_get0_key issue?

kroeckx · 2017-12-01T19:44:58Z

I've fixed the RSA_get0_key() call.

rcombs · 2017-12-20T04:32:40Z

Any remaining blockers here? It seems like the primary issue that's been raised is compatibility with both the 1.0 and 1.1 APIs, which is handled here. It appears that all review comments have been addressed. Is this just pending additional review?

noloader · 2018-01-14T13:59:03Z

From the TLS Working Group mailing list at 3rd WGLC: draft-ietf-tls-tls13:

All,

This is the 3rd working group last call (WGLC) announcement for draft-ietf-tls-t
ls13; it will run through January 26th.  This time the WGLC is for version -23 (
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/).  This WGLC is a targete
d WGLC because it only address changes introduced since the 2nd WGLC on version
-21, i.e., changes introduced in versions -22 and -23.  Note that the editor has
 kindly included a change log in s1.2 and the datatracker can also produce diffs
 (https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-tls13-21&url2=draft-ietf-tls-
tls13-23).  In general, we are considering all other material to have WG consens
us, so only critical issues should be raised about that material at this time.

Cheers,

spt

laomaiweng · 2018-02-08T02:35:59Z

On my Gentoo box (using OpenSSL 1.1.0g configured with --api=1.0.0 and no OPENSSL_API_COMPAT #defined at build time), this PR is still missing some stuff:

here is a first patch (against OpenSSH 7.6p1) to fix the remaining OpenSSL API changes that prevent building on my machine: https://592578.bugs.gentoo.org/attachment.cgi?id=518526
here is a second patch (still against OpenSSH 7.6p1) to rename pthread_{create,cancel,exit,join}() in auth-pam.c, since OpenSSL 1.1.0 with threads support on Linux unconditionally #includes <pthread.h>, which collides with these functions: https://bugs.gentoo.org/attachment.cgi?id=518528

Hope that helps!

okias · 2018-03-31T14:31:26Z

Will be this issue fixed in OpenSSH 7.7?

I migrated to OpenSSL 1.1.1, because of TLS 1.3 support, which is really nice to have!

AnimusPEXUS · 2018-08-21T18:39:36Z

as far as I can recall, openssh provides only executables. no shared objects. libssh and libssh2 build with openssl-1.1.x not bad. probably, now it is good opportunity for somebody to start concurrent project to openssh.. ;)

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. (From OE-Core rev: 1fa56a688237816fb47d92769e612e251384df83) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. (From OE-Core rev: 26edbb9546436e04b96ca77ea828a7a7831a8319) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This is a rebase of Kurt Roeckx's patch openssh/openssh-portable#48 On top of that, the calls to deprecated openssl functions were updated, and added a fix for redeclaration of pthread functions. Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. (From OE-Core rev: 15002f4fde44a66cadaa94989ca11a418a3db572) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. (From OE-Core rev: 0c9757e00e1763d10270d71a732620a1927874b6) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. (From OE-Core rev: 3b8bbd02fa0fbf74cb42fcf28596c551e9fa4447) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. (From OE-Core rev: 7c9eda8535b88a8889629b52342935894d71d9c9) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. (From OE-Core rev: e7ac137bfc59bc67e17d5372b59d20bdbfcc2550) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Source: poky MR: 00000 Type: Integration Disposition: Merged from poky ChangeID: 7294453 Description: After reading through this: openssh/openssh-portable#48 and this thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html I've concluded that this is the best of the three not-great options. The alternatives: - bundle libressl inside openssh packages - keep openssh dependent on openssl 1.0 and wait until upstream does something are both inferior. Libressl is used with openssh in OpenBSD and in OS X, so it did get at least some testing in the real world. (From OE-Core rev: e7ac137bfc59bc67e17d5372b59d20bdbfcc2550) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>

xnox · 2018-09-11T17:07:28Z

https://www.openssl.org/blog/blog/2018/09/11/release111/

Since 1.1.1 is our new LTS release we are strongly advising all users to upgrade as soon as possible.

Our previous LTS release (OpenSSL 1.0.2) will continue to receive full support until the end of this year. After that it will receive security fixes only. It will stop receiving all support at the end of 2019. Users of that release are strongly advised to upgrade to OpenSSL 1.1.1.

This is a rebase of Kurt Roeckx's patch openssh/openssh-portable#48 On top of that, the calls to deprecated openssl functions were updated, and added a fix for redeclaration of pthread functions. Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>

emaste · 2018-09-18T20:20:48Z

OpenSSL 1.1.x compatibility started arriving about a week ago: 482d23b

I cherry-picked the 1.1.x-compat commits on top of V_7_8_P1 (resolving trivial conflicts) and pushed the result here: https://github.com/emaste/openssh-portable/tree/v7.8p1-OpenSSL1.1

1.0.2o is now longer served. OpenSSH does currently not support 1.1 per: openssh/openssh-portable#48

daztucker · 2019-06-07T14:39:33Z

OpenSSL 1.1.x is now supported. Thanks.

Jakuje reviewed Oct 21, 2016

View reviewed changes

Jakuje reviewed Oct 27, 2016

View reviewed changes

bagajjal mentioned this pull request Mar 20, 2017

Regarding "error in libcrypto" PowerShell/Win32-OpenSSH#522

Closed

DomT4 mentioned this pull request May 2, 2017

[OpenSSH] OpenSSH v7.5p1, Homebrew revision 1 Fails to Build on OS X 'El Capitan' v10.11.6 Homebrew/homebrew-core#13132

Closed

5 tasks

davidben reviewed Oct 16, 2017

View reviewed changes

kroeckx mentioned this pull request Oct 29, 2017

Only reset the ctx when a cipher is given openssl/openssl#4613

Closed

kroeckx force-pushed the openssl-1.1.0 branch from 34b8595 to b22c000 Compare October 29, 2017 18:26

Make it build using OpenSSL 1.1.0

5a08c7f

kroeckx force-pushed the openssl-1.1.0 branch from b22c000 to 5a08c7f Compare October 29, 2017 18:28

Jakuje reviewed Nov 14, 2017

View reviewed changes

Don't call RSA_get0_key with NULL for the rsa key

8f084be

InuSasha mentioned this pull request Feb 20, 2018

openssl: update to 1.1.1+ LibreELEC/LibreELEC.tv#2471

Merged

thewtex added a commit to thewtex/dockcross that referenced this pull request Dec 17, 2018

base: Bump openssl to 1.0.2q

9116bb2

1.0.2o is now longer served. OpenSSH does currently not support 1.1 per: openssh/openssh-portable#48

thewtex added a commit to thewtex/dockcross that referenced this pull request Dec 17, 2018

base: Bump openssl to 1.0.2q

148cb4c

1.0.2o is now longer served. OpenSSH does currently not support 1.1 per: openssh/openssh-portable#48

daztucker closed this Jun 7, 2019

		attribs[2].ulValueLen, NULL);
		if (RSA_set0_key(rsa, rsa_n, rsa_e, NULL) == 0)

Make it build using OpenSSL 1.1.0 #48

Make it build using OpenSSL 1.1.0 #48

Conversation

kroeckx commented Sep 18, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kroeckx commented Oct 21, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Jakuje commented Nov 2, 2016

noloader commented Apr 2, 2017

cookiengineer commented Apr 9, 2017 • edited

Jakuje commented Apr 9, 2017

davidben left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kroeckx commented Oct 29, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rcombs commented Dec 1, 2017

kroeckx commented Dec 1, 2017

rcombs commented Dec 20, 2017

noloader commented Jan 14, 2018 • edited

laomaiweng commented Feb 8, 2018

okias commented Mar 31, 2018

AnimusPEXUS commented Aug 21, 2018

xnox commented Sep 11, 2018

emaste commented Sep 18, 2018

daztucker commented Jun 7, 2019

kroeckx commented Oct 21, 2016 •

edited

cookiengineer commented Apr 9, 2017 •

edited

noloader commented Jan 14, 2018 •

edited