similar to: Status of OpenSSL 1.1 support

On 11/02/2016 01:43 AM, Colin Watson wrote: > On Sun, Sep 18, 2016 at 08:22:31PM +0200, Kurt Roeckx wrote: >> Attached is a patch that add supports for building against OpenSSL >> 1.1.0. I also made a github pull request for it at: >> https://github.com/openssh/openssh-portable/pull/48 > Hi, > > Debian unstable now has OpenSSL 1.1.0 as the default, so I'll have to

On 2020-05-22 22:54:18 [-0700], Wayne Davison via rsync wrote: > Thanks for the optimizing patches, Jorrit! I've merged your latest changes > into the git master branch. Wouldn't it be better to add support for a crypto library (like openssl) which would provide optimized algorithms for more than just one platform without the need to maintain it separately? > ..wayne..

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> OpenSSL 3.1.0 uses the same ABI as OpenSSL 3.0.x series. Further 3.1.x release are just stable updates and no ABI change (is expected) just like the 3.0.x series. Relax the version check for OpenSSL 3+ and rely on ABI compatibility. Signed-off-by: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> ---

Dear Damien, On Wed, Apr 19, 2023 at 9:55?AM Damien Miller <djm at mindrot.org> wrote: > > On Wed, 19 Apr 2023, Dmitry Belyavskiy wrote: > > > > While I'm sure this is good for RHEL/rawhide users who care about FIPS, > > > Portable OpenSSH won't be able to merge this. We explictly aim to support > > > LibreSSL's libcrypto as well as

I added ZSTD support to OpenSSH roughly over a year and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

On Sat, Oct 14, 2017 at 11:40:30AM +1100, Damien Miller wrote: > On Fri, 13 Oct 2017, Sebastian Andrzej Siewior wrote: > > more or less a year ago Kurt Roeckx provided an initial port towards the > > OpenSSL 1.1 API [0]. The patch has been left untouched [1] and it has > > been complained about a missing compat layer of the new vs the old API > > within the OpenSSL

I hacked zstd support into OpenSSH a while ago and just started to clean it up in the recent days. The cleanup includes configuration support among other things that I did not have. During testing I noticed the following differences compared to zlib: - highly interactive shell output (as in refreshed at a _very_ high rate) may result in higher bandwidth compared to zlib. Since zstd is quicker

On Mon, 14 Nov 2016, Jakub Jelen wrote: > Thank you for the comments. I understand the upstream directions and > that the OpenSSL step is not ideal. The distros will probably have to > carry these patches until the changes will settle down a bit. AFAIK Red Hat employs at least one OpenSSL maintainer. What is their view on this situation? > Other possible solution we were discussing

On 27 August 2017 08:32:06 CEST, Timo Sirainen <tss at iki.fi> wrote: >> DEF(SET_STR, ssl_protocols), >> DEF(SET_STR, ssl_cert_username_field), >> DEF(SET_STR, ssl_crypto_device), >> + DEF(SET_STR, ssl_lowest_version), > >Does it really require a new setting? Couldn't it use the existing >ssl_protocols setting? You need to set a minimal version.

The openssl library in Debian unstable (targeting Buster) supports TLS1.2 by default. The library itself supports also TLS1.1 and TLS1.0. If the admin decides to also support TLS1.[01] users he can then enable the lower protocol version in case the users can't update their system. Signed-off-by: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> --- src/config/all-settings.c

On 2020-02-20 20:06:39 [+0100], Markus Ueberall wrote: > On 2020-02-09 23:19, Sebastian Andrzej Siewior wrote: > > [...] > > My primar motivation to use SHA1 for checksumming (by default) instead > > of MD5 is not the additional security bits but performance. On a decent > > x86 box the SHA1 performance is almost the same as MD5's but with > > acceleration it

On 2020-03-17 00:03:03 [+0100], Dimitrios Apostolou via rsync wrote: > On Thursday, February 20, 2020 10:34:53 PM CET, Sebastian Andrzej Siewior > via rsync wrote: > > > > I'm still not sure if rsync requires a cryptographic hash _or_ if a > > strong hash like xxHash64 would be just fine for the job. > > I'm fairly sure the hash should *not* be easy to

Unregister the driver before removing multi-instance hotplug callbacks. This order avoids the warning issued from __cpuhp_remove_state_cpuslocked when the number of remaining instances isn't yet zero. Fixes: 8017c279196a ("net/virtio-net: Convert to hotplug state machine") Cc: Sebastian Andrzej Siewior <bigeasy at linutronix.de> Signed-off-by: Andrew Jones <drjones at

Unregister the driver before removing multi-instance hotplug callbacks. This order avoids the warning issued from __cpuhp_remove_state_cpuslocked when the number of remaining instances isn't yet zero. Fixes: 8017c279196a ("net/virtio-net: Convert to hotplug state machine") Cc: Sebastian Andrzej Siewior <bigeasy at linutronix.de> Signed-off-by: Andrew Jones <drjones at

On Wed, 19 Feb 2020 at 06:38, Val Baranov <val.baranov at duke.edu> wrote: > AIX 7.1 TL5, OpenSSL ver. 1.1.1d. "vac.C" version 11.0.1.23 > Compilation error " The indirection operator cannot be applied to a pointer to an incomplete struct or union " (see full log below) produced for " libressl-api-compat.c ". > No such error if compiled with OpenSSL

I added ZSTD support to OpenSSH roughly three years ago and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

On 2020-09-07 11:21:13 [+1000], Darren Tucker wrote: > The zstd part would be a larger discussion because we would need to > either carry it as a Portable patch or have zstd added to OpenBSD > base, and I don't know if that would be accepted. Do you have any > performance numbers for zstd in this application? A key stroke is here 10 bytes of raw data which zstd compresses usually

On Mon, Oct 16, 2017 at 12:40:54AM +0200, Ingo Schwarze wrote: > Colin Watson wrote on Sun, Oct 15, 2017 at 10:51:46PM +0100: > > Is it actually a requirement that an API compatibility layer be > > maintained by the OpenSSL team, or could a hypothetical group of > > external developers interested in breaking this stalemate fork > > openssl-compat.tar.gz, stick it in a

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> The "zstd at breakpoint.cc" compression algorithm enables ZSTD based compression as defined in RFC8478. The compression is delayed until the server sends the SSH_MSG_USERAUTH_SUCCESS which is the same time as with the "zlib at openssh.com" method. Signed-off-by: Sebastian Andrzej Siewior <sebastian at

Hi Ingo, On Wed, Oct 18, 2017 at 4:15 PM, Ingo Schwarze <schwarze at usta.de> wrote: > Hi, > > jpbion at jfwest.com wrote on Wed, Oct 18, 2017 at 05:53:21AM -0700: > >> 4) As a first result, with no judgement on anyone, just looking at the >> data - the root cause of this issue seems to be the split of LibreSSL >> from OpenSSL > > No, you are totally