similar to: Status of OpenSSL 1.1 support - Thoughts

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*

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

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, 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,

libressl is a leaner and safer openssl Sent from ProtonMail Mobile On Wed, Nov 2, 2016 at 12:39 PM, Michael A. Peters <'mpeters at domblogger.net'> wrote: 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: >

On 2018-04-07 11:24, Bernard Spil wrote: > On 2018-04-07 9:04, Joel Sing wrote: >> On Friday 06 April 2018 21:31:01 Bernard Spil wrote: >>> Hi, >>> >>> When using OpenSSH with LibreSSL 2.7.x it cannot read existing RSA >>> and >>> ECDSA private keys. >>> >>> Error loading key "./id_rsa": invalid format

On Friday 06 April 2018 21:31:01 Bernard Spil wrote: > Hi, > > When using OpenSSH with LibreSSL 2.7.x it cannot read existing RSA and > ECDSA private keys. > > Error loading key "./id_rsa": invalid format > > Rebuilding OpenSSH with LibreSSL 2.6.x fixes the issue. I had fixed this > issue early on with LibreSSL 2.7 by converting the key to "new

--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

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

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 04:25 AM, Aki Tuomi wrote: > 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 >

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 needed. Note the word think. It certainly appears to be working anyway with it. On 11/02/2016 04:07 AM, Aki Tuomi wrote: > After doing some testing by myself, I noticed that libressl, for some > unknown reason, defines > > #define

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.

Howdy, I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the ssl implementation. Unfortunately, this fails to work (tested on Debian Unstable and Gentoo): cd libressl-2.2.4 ./configure --prefix=/opt/libressl-2.2.4 && make -j8 && sudo make install cd ../openssh-7.1p1 ./configure --with-ssl-dir=/opt/libressl-2.2.4 fails with: checking OpenSSL header version...

On 08/23/2015 07:25 AM, Always Learning wrote: > > On Sat, 2015-08-22 at 08:05 -0700, Alice Wonder wrote: > >> Thunderbird has a MITM vulnerability with its otherwise rather groovy >> auto-configuration feature. > >> https://librelamp.com/FooBird#security >> >> has what I think would be the easiest solution while keeping the >> ability to

Yes and no... At least as I understand it (Disclaimer: There are things I am pretty sure that I don't understand properly, somewhere in the Bermuda triangle beween CA bundles, TLS protocols, and Server-side settings), there are two sided to this: One is that various *.r-project.org servers got hit by a fumble where a higher-up certificate in the chain of trust expired before the

On Sat, May 30, 2020 at 11:32 PM G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: [...] > Btw. why does this affect openssl? That root cert was published in > 2010, surely openssl should know about it? Maybe libcurl / openssl > only uses the chain provided by the server? Without trying to use an > alternate chain? Yes, indeed it seems that old OpenSSL versions cannot handle

As I said, there is stuff that I don't understand in here.... (including why browsers apparently do trust alternative chains) -pd > On 10 Jun 2020, at 01:53 , Simon Urbanek <simon.urbanek at R-project.org> wrote: > > You are making a very strong assumption that finding an alternative chain of trust is safe. I'd argue it's not - it means that an adversary could

Was this resolved upstream or is this something that R should/could fix? If the latter, could this also go into the "emergency release" R 4.0.2 that is scheduled for 2020-06-22? My $.02 /Henrik On Sun, May 31, 2020 at 8:13 AM G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: > > Btw. it would be also possible to create a macOS R installer that > embeds a static or

On Mon, Nov 9, 2015 at 5:35 PM, Darren Tucker <dtucker at zip.com.au> wrote: > On Tue, Nov 10, 2015 at 9:22 AM, Austin English <austinenglish at gmail.com> wrote: >> Howdy, >> >> I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the >> ssl implementation. Unfortunately, this fails to work (tested on >> Debian Unstable and Gentoo):