Quantcast

please make clear on website that 1.1.0e is Development release, not GA / Production release

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

please make clear on website that 1.1.0e is Development release, not GA / Production release

Jason Vas Dias
Hi - much thanks for many years of great OpenSSL releases,
but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k
release on the website as the 'latest / best OpenSSL release' - this just
wastes everybody's time .  No using software can use this release,
such as the latest releases of OpenSSH,  ISC BIND (named) / ISC DHCP,  ntpd
(... the list can go on and on - does the latest httpd  compile with it? )
 without major restructuring .
I did waste a few hours today getting ISC BIND 9.11.0-P3 & DHCP 4.3.5
& ntpd 4.3.93 to use 1.1.0e , (I can generate & send the patches for
them to anyone who wants them), and wpa_supplicant v2.7 ,   and got
the latest version of OpenSSH (v7.4.P1) to at least compile with it,
but that version of OpenSSH is broken in so many ways because of
openssl 1.1.0  - it can't even read or write its ED25519
/etc/ssh_host_ed25519.key file. It looks like too much work to support
the new 1.1.0 API  across all current OpenSSL using applications - and
what do these API "improvements" really get us?
At least ISC BIND & dhclient & wpa_supplican do now work with it  -
these are the programs I depend on for my internet connection -  but I
haven't really rested their OpenSSL using features much . And then I
saw the list of vulnerabilities which apply only to the 1.1.0 branch
and I realized "Oh, this is a development branch"  .
Now tonight / tomorrow I'll be recompiling OpenSSH, BIND, DHCP &
wpa_supplicant to use 1.0.2k & undoing all the patches I made (which
mainly
involved including the '*_lo?cl.h' & '*_int.h'  headers where the API
they were using moved, which are now not installed in
/usr/include/openssl ). Why you are now
hiding the API used by 90% of OpenSSL's core users I do not understand.
Couldn't you please inform users of this on the main openssl.org web-page ?
I appreciate the 1.1.0 software does pass its test suite, and
may introduce some API "improvements", if the old OpenSSL API did
not  have such a vast legacy of users to support - I question how any
API "improvement" can outweigh the cost of restructuring all current
using code to use it, especially with such a complex and typically
mission critical
library such as OpenSSL.
Sorry, I just had to let you have my two cents worth here.
Thanks & Regards,
Jason.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please make clear on website that 1.1.0e is Development release, not GA / Production release

Kurt Roeckx
On Mon, Mar 20, 2017 at 10:41:12PM +0000, Jason Vas Dias wrote:
> Hi - much thanks for many years of great OpenSSL releases,
> but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k
> release on the website as the 'latest / best OpenSSL release' - this just
> wastes everybody's time .  No using software can use this release,
> such as the latest releases of OpenSSH,  ISC BIND (named) / ISC DHCP,  ntpd
> (... the list can go on and on - does the latest httpd  compile with it? )

I have send patches for all of those that you just mentioned so
that they can get build using both 1.0.2 and 1.1.0.

> I did waste a few hours today getting ISC BIND 9.11.0-P3 & DHCP 4.3.5
> & ntpd 4.3.93 to use 1.1.0e , (I can generate & send the patches for
> them to anyone who wants them),

DHCP 4.3.5 seems to work just fine with 1.1.0.

The latest ntp release is 4.2.8p9 which should just work with
openssl 1.1.0. (I have no idea why they don't list it on their
download page now, or why the development version is so old.)

bind has applied patches, I'm just not sure in which branches.

> the latest version of OpenSSH (v7.4.P1) to at least compile with it,
> but that version of OpenSSH is broken in so many ways because of
> openssl 1.1.0  - it can't even read or write its ED25519
> /etc/ssh_host_ed25519.key file.

The ed25519 support in openssh doesn't even come from openssl.

> which mainly
> involved including the '*_lo?cl.h' & '*_int.h'  headers

Including the internal headers is not a good patch. This will
break.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please make clear on website that 1.1.0e is Development release, not GA / Production release

Jason Vas Dias
On 20/03/2017, Kurt Roeckx <[hidden email]> wrote:

> On Mon, Mar 20, 2017 at 10:41:12PM +0000, Jason Vas Dias wrote:
>> Hi - much thanks for many years of great OpenSSL releases,
>> but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k
>> release on the website as the 'latest / best OpenSSL release' - this just
>> wastes everybody's time .  No using software can use this release,
>> such as the latest releases of OpenSSH,  ISC BIND (named) / ISC DHCP,
>> ntpd
>> (... the list can go on and on - does the latest httpd  compile with it?
>> )
>
> I have send patches for all of those that you just mentioned so
> that they can get build using both 1.0.2 and 1.1.0.

Great, thanks, but they are not being distributed anywhere .
Please could you send the patch sets against bind-9.11.0-P3
& DHCP 9.3.5 to me ?

>
>> I did waste a few hours today getting ISC BIND 9.11.0-P3 & DHCP 4.3.5
>> & ntpd 4.3.93 to use 1.1.0e , (I can generate & send the patches for
>> them to anyone who wants them),
>
> DHCP 4.3.5 seems to work just fine with 1.1.0.
>

Yes, as I said, named & dhcp & wpa_supplicant are working fine with 1.1.0 and
after  patching   to use the internal 1.1.0 headers.  DHCP uses OpenSSL via the
BIND libisc & libdns libraries, anyway , so doesn't really count as an OpenSSL
user in its own right.

None of their latest versions can compile unmodified against 1.1.0 .

That is why I think it is somewhat premature to call 1.1.0 the official
stable OpenSSL release.

> The latest ntp release is 4.2.8p9 which should just work with
> openssl 1.1.0. (I have no idea why they don't list it on their
> download page now, or why the development version is so old.)
>

No, the latest version is 4.3.93 , not 4.2.8p9,  and it also needed to include
                                           ^                  ^
internal 1.1.0 headers to compile.

> bind has applied patches, I'm just not sure in which branches.
>
It may be years yet before they see the light of day in a BIND release.

>> the latest version of OpenSSH (v7.4.P1) to at least compile with it,
>> but that version of OpenSSH is broken in so many ways because of
>> openssl 1.1.0  - it can't even read or write its ED25519
>> /etc/ssh_host_ed25519.key file.
>
> The ed25519 support in openssh doesn't even come from openssl.
>
What happens is OpenSSH's cipher.c calls
       if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,
          (do_encrypt == CIPHER_ENCRYPT)) == 0) {
                ret = SSH_ERR_LIBCRYPTO_ERROR;
                goto out;
        }
which always does 'goto out' for any ED25519 file.
OpenSSL's EVP_CipherInit calls EVP_CipherInit_ex which fails in this case.
I'm not really an OpenSSL / cryptography expert (but have written a few
SSL / plain transparent I/O modules in C/C++  in my time), but I can
see OpenSSH
is expecting OpenSSL to respond in a certain way to these parameters which
it does not do in 1.1.0, but does in 1.0.2x .

>> which mainly
>> involved including the '*_lo?cl.h' & '*_int.h'  headers
>
> Including the internal headers is not a good patch. This will
> break.
>

It doesn't break at all - the code remains 100% unchanged  - just different
headers need including - and seems to work fine including the API
hiding headers.
But considering the work necessary to make all OpenSSH using apps include those
headers , it doesn't seem worth it.

My question is really, why ?  Why make ALL OpenSSL users
(and there are thousands of them) now jump through new hoops
to use the same API they've been using for years ? What does it get them?

And my point is really not to criticize your effort, it is just a plea to make
clear on the web-page that the 1.1.0 branch is a development branch and
does not work yet with most OpenSSL using applications .

OpenSSL in its 1.0.2 incarnation has been hardened by over (10,15,20)? years
of testing , and its API is usable by all OpenSSL using applications,
unlike 1.1.0 .

Out of these using applications, which have their latest versions switched
to using the 1.1.0 API :  bind, OpenSSH, httpd, firefox ?
AFAICS, none.

It is just premature and confusing and a timewaster to claim the latest
stable OpenSSL release is 1.1.0 on the main web page. No using applications
can use it yet.  Give them a few years, and they will .  But please, make clear
on the web-page that most applications still use the 1.0.2 API .

Friendly Regards,
Jason
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please make clear on website that 1.1.0e is Development release, not GA / Production release

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Tue, 21 Mar 2017 00:13:57 +0000, Jason Vas Dias <[hidden email]> said:

jason.vas.dias> On 20/03/2017, Kurt Roeckx <[hidden email]> wrote:
jason.vas.dias> > The ed25519 support in openssh doesn't even come from openssl.
jason.vas.dias> >
jason.vas.dias> What happens is OpenSSH's cipher.c calls
jason.vas.dias>        if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,
jason.vas.dias>           (do_encrypt == CIPHER_ENCRYPT)) == 0) {
jason.vas.dias> ret = SSH_ERR_LIBCRYPTO_ERROR;
jason.vas.dias> goto out;
jason.vas.dias> }
jason.vas.dias> which always does 'goto out' for any ED25519 file.

That would happen if ssh_host_ed25519_key is password protected and
the cipher used to encrypt the key isn't recognised in OpenSSL 1.1.0
(and considering the current master of openssh-portable doesn't build
cleanly against OpenSSL 1.1.0e and I therefore suppose you've hacked
around, I can't even begin to say where the fault came in).  It also
depends on your OpenSSL configuration, since you can disable most
algorithms it carries...

jason.vas.dias> >> which mainly
jason.vas.dias> >> involved including the '*_lo?cl.h' & '*_int.h'  headers
jason.vas.dias> >
jason.vas.dias> > Including the internal headers is not a good patch. This will
jason.vas.dias> > break.
jason.vas.dias> >
jason.vas.dias>
jason.vas.dias> It doesn't break at all - the code remains 100% unchanged  - just different
jason.vas.dias> headers need including - and seems to work fine including the API
jason.vas.dias> hiding headers.

The structures you find in there are made private for a reason, we
need the liberty to make changes in them in future developments
without disturbing the ABI (not just the API).  So some time in the
future, it will break.

jason.vas.dias> And my point is really not to criticize your effort, it is just a plea to make
jason.vas.dias> clear on the web-page that the 1.1.0 branch is a development branch and
jason.vas.dias> does not work yet with most OpenSSL using applications .

It isn't a development branch.  We see it as a stable release, i.e. no
further development apart from bug fixes.  "master" is the development
branch.

jason.vas.dias> OpenSSL in its 1.0.2 incarnation has been hardened by over (10,15,20)? years
jason.vas.dias> of testing , and its API is usable by all OpenSSL using applications,
jason.vas.dias> unlike 1.1.0 .

Jyst to put things in perspective, OpenSSL 1.0.0 was released
2010-Mar-29.  That was the start of the 1.0.x series.  OpenSSL 1.0.2
was released 2015-Jan-22.

OpenSSL 1.1.0 marks the start of the 1.1.x series, which isn't source
compatible with the 1.0.x series.  We have talked about this in
different ways even before the first Alpha release was made (over a
year ago).

Either way, the 1.0.2 branch is supported until the end of 2019.
One could say that's how long other application authors have to rework
their source, although that's not really true since anyone can keep
the 1.0.2 source around as long as they want (hey, even we do).

Maybe you expected all applications to have converted the moment we
declared our 1.1.0 release stable?  That will not happen...  as far as
we've observed, most are hardly even looking before we've made a
stable release (which I agree is unfortunate).

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please make clear on website that 1.1.0e is Development release, not GA / Production release

Peter Waltenberg

Just commenting on this: I had very few problems moving from 1.0.2 to 1.1.0. We'd already cleaned up most of the issues OpenSSL fixed between 1.0.2 and 1.1.0, those fixups were well isolated so migrating was just a matter of ifdef'ing out accessors/allocators/deallocators we'd created to civilize the API and replace those with the equivalents native to 1.1.0.
Things like that you can't fix without breaking someone, and without fixing that you can't provide stable ABI's going forward, as Richard says someone will break at some point when you do that anyway.  I'll concede we realized ABI stability would be an issue well in advance of 1.1.0 but it was just good defensive programming practice achieved that, not inside information.

Mind you, some of the problems in 1.1.0x are awesome, older HP/UX PA-RISC compilers turn some of the macros deep in OpenSSL to local functions - embedded in every object file. Our footprint there went from 2M to 20M. Solaris had similar issues but not quite as bad in practice.

Peter

-----"openssl-dev" <[hidden email]> wrote: -----
To: [hidden email]
From: Richard Levitte
Sent by: "openssl-dev"
Date: 03/21/2017 06:56PM
Subject: Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release

In message <[hidden email]> on Tue, 21 Mar 2017 00:13:57 +0000, Jason Vas Dias <[hidden email]> said:

jason.vas.dias> On 20/03/2017, Kurt Roeckx <[hidden email]> wrote:
jason.vas.dias> > The ed25519 support in openssh doesn't even come from openssl.
jason.vas.dias> >
jason.vas.dias> What happens is OpenSSH's cipher.c calls
jason.vas.dias>        if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,
jason.vas.dias>           (do_encrypt == CIPHER_ENCRYPT)) == 0) {
jason.vas.dias> ret = SSH_ERR_LIBCRYPTO_ERROR;
jason.vas.dias> goto out;
jason.vas.dias> }
jason.vas.dias> which always does 'goto out' for any ED25519 file.

That would happen if ssh_host_ed25519_key is password protected and
the cipher used to encrypt the key isn't recognised in OpenSSL 1.1.0
(and considering the current master of openssh-portable doesn't build
cleanly against OpenSSL 1.1.0e and I therefore suppose you've hacked
around, I can't even begin to say where the fault came in).  It also
depends on your OpenSSL configuration, since you can disable most
algorithms it carries...

jason.vas.dias> >> which mainly
jason.vas.dias> >> involved including the '*_lo?cl.h' & '*_int.h'  headers
jason.vas.dias> >
jason.vas.dias> > Including the internal headers is not a good patch. This will
jason.vas.dias> > break.
jason.vas.dias> >
jason.vas.dias>
jason.vas.dias> It doesn't break at all - the code remains 100% unchanged  - just different
jason.vas.dias> headers need including - and seems to work fine including the API
jason.vas.dias> hiding headers.

The structures you find in there are made private for a reason, we
need the liberty to make changes in them in future developments
without disturbing the ABI (not just the API).  So some time in the
future, it will break.

jason.vas.dias> And my point is really not to criticize your effort, it is just a plea to make
jason.vas.dias> clear on the web-page that the 1.1.0 branch is a development branch and
jason.vas.dias> does not work yet with most OpenSSL using applications .

It isn't a development branch.  We see it as a stable release, i.e. no
further development apart from bug fixes.  "master" is the development
branch.

jason.vas.dias> OpenSSL in its 1.0.2 incarnation has been hardened by over (10,15,20)? years
jason.vas.dias> of testing , and its API is usable by all OpenSSL using applications,
jason.vas.dias> unlike 1.1.0 .

Jyst to put things in perspective, OpenSSL 1.0.0 was released
2010-Mar-29.  That was the start of the 1.0.x series.  OpenSSL 1.0.2
was released 2015-Jan-22.

OpenSSL 1.1.0 marks the start of the 1.1.x series, which isn't source
compatible with the 1.0.x series.  We have talked about this in
different ways even before the first Alpha release was made (over a
year ago).

Either way, the 1.0.2 branch is supported until the end of 2019.
One could say that's how long other application authors have to rework
their source, although that's not really true since anyone can keep
the 1.0.2 source around as long as they want (hey, even we do).

Maybe you expected all applications to have converted the moment we
declared our 1.1.0 release stable?  That will not happen...  as far as
we've observed, most are hardly even looking before we've made a
stable release (which I agree is unfortunate).

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please make clear on website that 1.1.0e is Development release, not GA / Production release

Richard Könning
In reply to this post by Jason Vas Dias
On 21.03.2017 01:13,  Jason Vas Dias wrote:
> On 20/03/2017, Kurt Roeckx <[hidden email]> wrote:
>> The latest ntp release is 4.2.8p9 which should just work with
>> openssl 1.1.0. (I have no idea why they don't list it on their
>> download page now, or why the development version is so old.)
>>
>
> No, the latest version is 4.3.93 , not 4.2.8p9,  and it also needed to include
>                                             ^                  ^
> internal 1.1.0 headers to compile.

The latest stable NTP version is 4.2.8p9 (see e.g.
http://support.ntp.org/rss/releases.xml), the latest development version
is 4.3.93 and is a half year older than 4.2.8p9.

Ciao,
Richard
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please make clear on website that 1.1.0e is Development release, not GA / Production release

Jason Vas Dias
In reply to this post by Richard Levitte - VMS Whacker-2

Thanks for your informative replies!
I hope BIND, OpenSSH et al start using
the 1.1.0 API soon.

RE:
<cite>
jason.vas.dias> On 20/03/2017, Kurt Roeckx <[hidden email]> wrote:
jason.vas.dias> > The ed25519 support in openssh doesn't even come from openssl.
jason.vas.dias> >
jason.vas.dias> What happens is OpenSSH's cipher.c calls
jason.vas.dias>        if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,
jason.vas.dias>           (do_encrypt == CIPHER_ENCRYPT)) == 0) {
jason.vas.dias>                 ret = SSH_ERR_LIBCRYPTO_ERROR;
jason.vas.dias>                 goto out;
jason.vas.dias>         }
jason.vas.dias> which always does 'goto out' for any ED25519 file.

That would happen if ssh_host_ed25519_key is password protected and
the cipher used to encrypt the key isn't recognised in OpenSSL 1.1.0
(and considering the current master of openssh-portable doesn't build
cleanly against OpenSSL 1.1.0e and I therefore suppose you've hacked
around, I can't even begin to say where the fault came in).  It also
depends on your OpenSSL configuration, since you can disable most
algorithms it carries...
</cite>

But none of my host keys were password protected.

They were just what resulted from the command:
$ ssh-keygen -A
which is run on initial openssh installation.

The modifications I made were trivial :
o Including the hidden API headers ,
o initializing automatic SSL structs
    - ie '{struct}_CTX v ={0};' , not
          '{struct}_CTX v;'
   ( else the {struct}_init(&v) function
     ( I think evp_init() )
     could try free()-ing garbage pointer
     members ( in named ) )
o changing some structure member references
   from s->m to s.m - these were verified by
   compiler.
That really is the extent of all mods I made
to openssh / BIND .

Openssh was then unable to read or write the
existing /etc/ssh_host_ed25519_key file ( not PW protected ), so NO ssh app can run, and
'ssh_keygen -A'  failed to write a new ed25519
key file (not pw protected) when I moved all the old files out of the way , failing ( under gdb ) at that point in the
cipher_init() code I posted before .

If anyone has managed to get openssh working
under OpenSSL 1.1.0 please let me know & I'll
try upgrading again.

But until 1.1.0 adoption becomes more widespread, I still think it would be helpful
if the main openssl.org webpage let users
know this is the case , with a statement such
as 'most openssl using applications have not
upgraded to 1.1.0 yet' . This would prevent
others from wasting time as I was led to do.

Regards, Jason


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: please make clear on website that 1.1.0e is Development release, not GA / Production release

wrowe
In reply to this post by Jason Vas Dias
On Mon, Mar 20, 2017 at 5:41 PM, Jason Vas Dias
<[hidden email]> wrote:
> Hi - much thanks for many years of great OpenSSL releases,
> but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k
> release on the website as the 'latest / best OpenSSL release' - this just
> wastes everybody's time .  No using software can use this release,
> such as the latest releases of OpenSSH,  ISC BIND (named) / ISC DHCP,  ntpd
> (... the list can go on and on - does the latest httpd  compile with it? )
>  without major restructuring .

Just to add to your list, Apache httpd 2.4.26 will support 1.1.0 (and those
patches are already on the 2.4 development branch.)

That said, 1.1.0 is the latest, and most complete (best) implementation.
That information was not incorrect.

Perhaps the team could add "most widely adopted" to the description of 1.0.2
for the time being, until the released sources of many common tools do adopt
the necessary API changes? But that really isn't the OpenSSL project's issue.

The Apache httpd project is also looking at how to efficiently adopt PCRE 10,
which is *long* established as the best/current software since a refactoring
some years ago, and somewhat similarly neglected by consuming projects.
It is not the OSS author's job to strong-arm downstream (e.g. dependent)
projects, but simply to provide the best OSS they can. When it breaks you
get to keep every line of source code.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Loading...