similar to: OpenSSL 1.1 support status : what next?

Hello Ingo, On Fri, Jun 23, 2017 at 1:26 AM, Ingo Schwarze <schwarze at usta.de> wrote: > > Hi Emmanuel, > > Emmanuel Deloget wrote on Fri, Jun 23, 2017 at 12:26:47AM +0200: > > > * the openssl team has no real incentive to propose a shim ; > > If major application projects refuse to support their new release, > thus putting pressure on operating system

OpenSC has taken a different approach to OpenSSL-1.1. Rather then writing a shim for OpenSSL-1.1, the OpenSC code has been converted to the OpenSSL-1.1 API and a sc-ossl-compat.h" file consisting of defines and macros was written to support older versions of OpenSSL and Libressl. https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h The nice part of this approach is

On 6/24/2017 11:35 AM, Emmanuel Deloget wrote: > Hello Douglas, > > On Fri, Jun 23, 2017 at 9:16 PM, Douglas E Engert <deengert at gmail.com <mailto:deengert at gmail.com>> wrote: > > OpenSC has taken a different approach to OpenSSL-1.1. Rather then writing > > a shim for OpenSSL-1.1, the OpenSC code has been converted to > > the OpenSSL-1.1 API and a

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

OpenSSL developers believed that there was a need for a significant change. A part of that change was a conscious choice to break (some of) the existing API. They considered that pain unavoidable. So far I happen to agree with their rationale and approach. Move from visible internal structures to accessor functions is a good thing, regardless of what you may think of it. And the new API *is*

As far as I can see, here is a summary of the situation, and there's a point to this, but I only make it in step (4), needing the first three steps to set up a background to keep my own thoughts clear: 1) Fedora (via Jakub) shows it's possible to patch OpenSSH. 2) OpenVPN (via gert) shows it's possible to build a 'shim' of sorts that allows code to work with libreSSL and

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

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

Hi, On Thu, Oct 19, 2017 at 09:43:41AM +1100, Damien Miller wrote: > You've got this exactly backwards. We don't want a shim that allows > OpenSSL-1.1 to present a OpenSSL-1.0 API. We want a shim that allows > us to use the OpenSSL-1.1 API when using OpenSSL-1.0, so we don't have > to maintain a forest of #ifdefs. For obvious reasons this shim cannot exist. If the

On Wed, 2 Nov 2016, Stuart Henderson wrote: > On 2016-11-02, Jakub Jelen <jjelen at redhat.com> wrote: > > The current set of patches are rebased on current upstream is attached > > with few more tweaks needed to build, pass testsuite and make it work. > > The upstream review and insight would be helpful. > > Since these are going to break things with LibreSSL,

Hello, On Sat, Dec 30, 2017 at 12:16 AM, Daniel Kahn Gillmor <dkg at fifthhorseman.net > wrote: > On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote: > > > > Perhaps if you're dead-set on this being so dangerous, > > It's not the developers who are dead-set on weak-keyed RSA being > insecure, it's the cryptanalysts who have shown that to be the

On Mon, 2017-10-16 at 17:18 +0200, Ingo Schwarze wrote: > > Fedora has the same policy, and so far has opted to ship a ~3600- > > line > > patch to OpenSSH to use the 1.1 API. > > Frankly, i would feel uncomfortable using OpenSSH on Fedora. Thank you for the support. Do you have any real reason to say so? Yes, we opted to improve existing patch, implement missing parts,

Hi, I have been working on a portable LibreSSL build tree for a little while to test the waters: http://github.com/busterb/libressl Someone noticed an issue with the arc4random implementation that I originally grabbed from libbsd https://github.com/busterb/libressl/issues/1 So, I looked at how OpenSSH handles it, and noticed that it uses the random functions from OpenSSL unconditionally to seed

I'm not sure I agree with Peter in respect to his comment about "building a dependency to systemd". The only time a "dependency" would be created is when the end-user would configure it to be there with a configure time flag of --with-systemd. Just having the code available and dormant without that flag being provided builds in no dependency whatsoever and gives the

Hi, We carry some compat code for old OpenSSL <1.1.1 and LibreSSL <3.1.0. OpenSSL 1.0.x is no longer supported upstream and AFAIK LibreSSL do not support old versions at all. I'd like to retire this config code, which would mean that users on platforms that include the versions of libcrypto would have to either bring their own libcrypto or compile OpenSSH --without-openssl (and accept

On Fri, 2019-07-12 at 15:54 +1000, Damien Miller wrote: > On Thu, 17 Jan 2019, Yuriy M. Kaminskiy wrote: > > > On some cpu's optimized chacha implementation in openssl (1.1.0+) > > is > > notably faster (and on others it is just faster) than generic C > > implementation in openssh. > > > > Sadly, openssl's chacha20-poly1305

Hi, 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 library [2]. This is how I reconstructed the situation as of today and I am not aware of any progress in regard to the newer library within the OpenSSH project.

Hi, On Tue, Oct 17, 2017 at 05:54:52AM -0600, The Doctor wrote: > The best solution is if (LIBRESSL) || (OPENSSL < 1010...) > > Else > > Whatever. > > Is that too much work? Littering code with #ifdef is almost never a good idea. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert

On 6/13/21 3:36 PM, Jim Klimov via Nut-upsdev wrote: > Haven't got many ideas on this today, preoccupied with other > house-work, but can share a couple :) > > Regarding two implementations - I believe NSS and OpenSSL are licensed > differently and/or are (initially were?) available non-overlapping on > different OSes. A quick googling now showed that they both were >

--On Tuesday, February 07, 2017 2:33 PM -0800 Alice Wonder <alice at domblogger.net> wrote: > What I mean is this - my LibreSSL package installs in /usr and not in > /opt and that is intentional, so that it is not possible to have both > opennsl-devel and libressl-devel installed at the same time, since they > both are the same API. That's the very problem that Software