Re: CVS: cvs.openbsd.org: src

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Kent R. Spillner-2
On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: [hidden email] 2014/07/10 08:29:03
>
> Modified files:
> usr.bin/rdist  : common.c config-data.h
>
> Log message:
> Assume POSIX: write() takes size_t and returns ssize_t

Do we need to do anything specific to build rdist after this change?


===> usr.bin/rdist
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c gram.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c /usr/src/usr.bin/rdist/message.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c /usr/src/usr.bin/rdist/lookup.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c /usr/src/usr.bin/rdist/isexec.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c /usr/src/usr.bin/rdist/expand.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c /usr/src/usr.bin/rdist/distopt.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c /usr/src/usr.bin/rdist/common.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c /usr/src/usr.bin/rdist/child.cIn file included from /usr/src/usr.bin/rdist/lookup.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'

cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c /usr/src/usr.bin/rdist/client.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c /usr/src/usr.bin/rdist/docmd.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c /usr/src/usr.bin/rdist/rdist.cIn file included from /usr/src/usr.bin/rdist/message.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'In file included from /usr/src/usr.bin/rdist/gram.y:34:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'

In file included from /usr/src/usr.bin/rdist/common.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'
/usr/src/usr.bin/rdist/common.c:80: warning: no previous prototype for 'xwrite'
In file included from /usr/src/usr.bin/rdist/expand.c:34:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'
In file included from /usr/src/usr.bin/rdist/distopt.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'
In file included from /usr/src/usr.bin/rdist/client.c:34:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'

In file included from /usr/src/usr.bin/rdist/isexec.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'
*** Error 1 in target 'common.o'
*** Error 1 in target 'lookup.o'
*** Error 1 in target 'message.o'
*** Error 1 in target 'gram.o'
In file included from /usr/src/usr.bin/rdist/child.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'
In file included from /usr/src/usr.bin/rdist/docmd.c:36:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'
/usr/src/usr.bin/rdist/child.c: In function 'readchild':
*** Error 1 in target 'distopt.o'
/usr/src/usr.bin/rdist/child.c:190: warning: implicit declaration of function 'xwrite'
*** Error 1 in target 'expand.o'
mandoc -Tlint /usr/src/usr.bin/rdist/rdist.1
/usr/src/usr.bin/rdist/client.c: In function 'sendfile':
/usr/src/usr.bin/rdist/client.c:444: warning: implicit declaration of function 'xwrite'
/usr/src/usr.bin/rdist/client.c: In function 'statupdate':
/usr/src/usr.bin/rdist/client.c:1040: warning: declaration of 'target' shadows a global declaration
/usr/src/usr.bin/rdist/client.c:54: warning: shadowed declaration is here
/usr/src/usr.bin/rdist/client.c: In function 'fullupdate':
/usr/src/usr.bin/rdist/client.c:1072: warning: declaration of 'target' shadows a global declaration
/usr/src/usr.bin/rdist/client.c:54: warning: shadowed declaration is here
*** Error 1 in target 'client.o'
*** Error 1 in target 'docmd.o'
*** Error 1 in target 'isexec.o'
*** Error 1 in target 'child.o'
In file included from /usr/src/usr.bin/rdist/rdist.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'
/usr/src/usr.bin/rdist/rdist.c: In function 'opendist':
/usr/src/usr.bin/rdist/rdist.c:305: warning: declaration of 'distfile' shadows a global declaration
/usr/src/usr.bin/rdist/rdist.c:42: warning: shadowed declaration is here
*** Error 1 in usr.bin/rdist (<sys.mk>:87 'rdist.o')
*** Error 1 (<sys.mk>:87 'child.o')
*** Error 1 (<sys.mk>:87 'isexec.o')
*** Error 1 (<sys.mk>:87 'docmd.o')
*** Error 1 (<sys.mk>:87 'client.o')
*** Error 1 (<sys.mk>:87 'expand.o')
*** Error 1 (<sys.mk>:87 'distopt.o')
*** Error 1 (<sys.mk>:87 'gram.o')
*** Error 1 (<sys.mk>:87 'message.o')
*** Error 1 (<sys.mk>:87 'lookup.o')
*** Error 1 (<sys.mk>:87 'common.o')
*** Error 2 in usr.bin (<bsd.subdir.mk>:48 'all')
*** Error 2 in . (<bsd.subdir.mk>:48 'all')
*** Error 2 in /usr/src (Makefile:82 'build')

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Miod Vallat
> On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote:
> > CVSROOT: /cvs
> > Module name: src
> > Changes by: [hidden email] 2014/07/10 08:29:03
> >
> > Modified files:
> > usr.bin/rdist  : common.c config-data.h
> >
> > Log message:
> > Assume POSIX: write() takes size_t and returns ssize_t
>
> Do we need to do anything specific to build rdist after this change?

A further commit to rdist/defs.h fixes this; it should appear in your
repository mirror shortly.

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Stuart Henderson
In reply to this post by Kent R. Spillner-2
On 2014/07/11 15:21, Bob Beck wrote:

> CVSROOT: /cvs
> Module name: src
> Changes by: [hidden email] 2014/07/11 15:21:59
>
> Modified files:
> lib/libssl/src/crypto: opensslv.h
>
> Log message:
> Provide LIBRESSL_VERSION_NUMBER for people who use such things to
> detect versions distinct from OPENSSL_BLAH_WOOF..
> ok jsing@ tedu@ deraadt@
>

I think it would ease porting work if the old OPENSSL_VERSION_NUMBER could
be retained and we use LIBRESSL_VERSION_NUMBER to distinguish LibreSSL
versions..


dovecot-2.2.10/dovecot-2.2.10/src/login-common/ssl-proxy-openssl.c
http://hg.dovecot.org/dovecot-2.2/file/fd0616d553b0/src/login-common/ssl-proxy-openssl.c#l130
32:#if !defined(OPENSSL_NO_ECDH) && OPENSSL_VERSION_NUMBER >= 0x10000000L
129:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L
1028:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L
1041:#if OPENSSL_VERSION_NUMBER >= 0x10002000L
1076:#if OPENSSL_VERSION_NUMBER >= 0x00907000L
1156:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L

chromium-34.0.1847.137/chromium-34.0.1847.137/net/socket/ssl_client_socket_openssl.cc
54:#if OPENSSL_VERSION_NUMBER < 0x1000103fL
...(checking for a version of openssl other than the embedded one?)


apache-httpd
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?revision=1598107&view=markup#l86
: #include <openssl/opensslv.h>
: #if (OPENSSL_VERSION_NUMBER >= 0x10001000)
: /* must be defined before including ssl.h */
: #define OPENSSL_NO_SSL_INTERN
: #endif

knot-dns
https://gitlab.labs.nic.cz/labs/knot/blob/2354047b6402aa68daffe96d6f82f30f0dad1cff/src/libknot/dnssec/config.h
: // ECDSA support requires OpenSSL version >= 1.0.1
: #if !defined(OPENSSL_NO_ECDSA) && OPENSSL_VERSION_NUMBER >= 0x10001000L
:   #define KNOT_ENABLE_ECDSA 1
: #else
:   #undef KNOT_ENABLE_ECDSA
: #endif

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Bob Beck-2
The OPENSSL_VERSION number is a guarantee for a certain version of the
ABI. As we dont' provide that (in fact much
of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use
the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION
is "bigger than 1.0.1g"'s.



On Fri, Jul 11, 2014 at 4:15 PM, Stuart Henderson <[hidden email]> wrote:

> On 2014/07/11 15:21, Bob Beck wrote:
>> CVSROOT:      /cvs
>> Module name:  src
>> Changes by:   [hidden email]    2014/07/11 15:21:59
>>
>> Modified files:
>>       lib/libssl/src/crypto: opensslv.h
>>
>> Log message:
>> Provide LIBRESSL_VERSION_NUMBER for people who use such things to
>> detect versions distinct from OPENSSL_BLAH_WOOF..
>> ok jsing@ tedu@ deraadt@
>>
>
> I think it would ease porting work if the old OPENSSL_VERSION_NUMBER could
> be retained and we use LIBRESSL_VERSION_NUMBER to distinguish LibreSSL
> versions..
>
>
> dovecot-2.2.10/dovecot-2.2.10/src/login-common/ssl-proxy-openssl.c
> http://hg.dovecot.org/dovecot-2.2/file/fd0616d553b0/src/login-common/ssl-proxy-openssl.c#l130
> 32:#if !defined(OPENSSL_NO_ECDH) && OPENSSL_VERSION_NUMBER >= 0x10000000L
> 129:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L
> 1028:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L
> 1041:#if OPENSSL_VERSION_NUMBER >= 0x10002000L
> 1076:#if OPENSSL_VERSION_NUMBER >= 0x00907000L
> 1156:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L
>
> chromium-34.0.1847.137/chromium-34.0.1847.137/net/socket/ssl_client_socket_openssl.cc
> 54:#if OPENSSL_VERSION_NUMBER < 0x1000103fL
> ...(checking for a version of openssl other than the embedded one?)
>
>
> apache-httpd
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?revision=1598107&view=markup#l86
> : #include <openssl/opensslv.h>
> : #if (OPENSSL_VERSION_NUMBER >= 0x10001000)
> : /* must be defined before including ssl.h */
> : #define OPENSSL_NO_SSL_INTERN
> : #endif
>
> knot-dns
> https://gitlab.labs.nic.cz/labs/knot/blob/2354047b6402aa68daffe96d6f82f30f0dad1cff/src/libknot/dnssec/config.h
> : // ECDSA support requires OpenSSL version >= 1.0.1
> : #if !defined(OPENSSL_NO_ECDSA) && OPENSSL_VERSION_NUMBER >= 0x10001000L
> :   #define KNOT_ENABLE_ECDSA 1
> : #else
> :   #undef KNOT_ENABLE_ECDSA
> : #endif
>

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Bob Beck-2
And seeing as how they moved 0.0.4 revisons in 9 years, call that
0.0.05 revisions per year, they have approximately 194 years of
OpenSSL releases before the version numbering space will collide.


On Fri, Jul 11, 2014 at 4:41 PM, Bob Beck <[hidden email]> wrote:

> The OPENSSL_VERSION number is a guarantee for a certain version of the
> ABI. As we dont' provide that (in fact much
> of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use
> the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION
> is "bigger than 1.0.1g"'s.
>
>
>
> On Fri, Jul 11, 2014 at 4:15 PM, Stuart Henderson <[hidden email]> wrote:
>> On 2014/07/11 15:21, Bob Beck wrote:
>>> CVSROOT:      /cvs
>>> Module name:  src
>>> Changes by:   [hidden email]    2014/07/11 15:21:59
>>>
>>> Modified files:
>>>       lib/libssl/src/crypto: opensslv.h
>>>
>>> Log message:
>>> Provide LIBRESSL_VERSION_NUMBER for people who use such things to
>>> detect versions distinct from OPENSSL_BLAH_WOOF..
>>> ok jsing@ tedu@ deraadt@
>>>
>>
>> I think it would ease porting work if the old OPENSSL_VERSION_NUMBER could
>> be retained and we use LIBRESSL_VERSION_NUMBER to distinguish LibreSSL
>> versions..
>>
>>
>> dovecot-2.2.10/dovecot-2.2.10/src/login-common/ssl-proxy-openssl.c
>> http://hg.dovecot.org/dovecot-2.2/file/fd0616d553b0/src/login-common/ssl-proxy-openssl.c#l130
>> 32:#if !defined(OPENSSL_NO_ECDH) && OPENSSL_VERSION_NUMBER >= 0x10000000L
>> 129:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L
>> 1028:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L
>> 1041:#if OPENSSL_VERSION_NUMBER >= 0x10002000L
>> 1076:#if OPENSSL_VERSION_NUMBER >= 0x00907000L
>> 1156:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L
>>
>> chromium-34.0.1847.137/chromium-34.0.1847.137/net/socket/ssl_client_socket_openssl.cc
>> 54:#if OPENSSL_VERSION_NUMBER < 0x1000103fL
>> ...(checking for a version of openssl other than the embedded one?)
>>
>>
>> apache-httpd
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?revision=1598107&view=markup#l86
>> : #include <openssl/opensslv.h>
>> : #if (OPENSSL_VERSION_NUMBER >= 0x10001000)
>> : /* must be defined before including ssl.h */
>> : #define OPENSSL_NO_SSL_INTERN
>> : #endif
>>
>> knot-dns
>> https://gitlab.labs.nic.cz/labs/knot/blob/2354047b6402aa68daffe96d6f82f30f0dad1cff/src/libknot/dnssec/config.h
>> : // ECDSA support requires OpenSSL version >= 1.0.1
>> : #if !defined(OPENSSL_NO_ECDSA) && OPENSSL_VERSION_NUMBER >= 0x10001000L
>> :   #define KNOT_ENABLE_ECDSA 1
>> : #else
>> :   #undef KNOT_ENABLE_ECDSA
>> : #endif
>>

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Stuart Henderson-6
I'm worried that bogus codepaths will be taken in software that expects a
certain openssl version - things failing to build we can cope with in ports
easily enough, I'm more concerned about software that does build but behaves
incorrectly at runtime.

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Theo de Raadt
In reply to this post by Kent R. Spillner-2
> I'm worried that bogus codepaths will be taken in software that expects a
> certain openssl version - things failing to build we can cope with in ports
> easily enough, I'm more concerned about software that does build but behaves
> incorrectly at runtime.

If the software is that fragile, then I am happy Bob, Joel, Miod, and Ted
are simplifying the interface.

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Matthew Dempsky-3
In reply to this post by Bob Beck-2
On Fri, Jul 11, 2014 at 3:41 PM, Bob Beck <[hidden email]> wrote:
> The OPENSSL_VERSION number is a guarantee for a certain version of the
> ABI. As we dont' provide that (in fact much
> of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use
> the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION
> is "bigger than 1.0.1g"'s.

By that argument, we won't be ABI compatible with OpenSSL 2.0 either,
so we shouldn't provide OPENSSL_VERSION at all.

My 2c is for keeping OPENSSL_VERSION_NUMBER as the most recent OpenSSL
version that we're *mostly* API/feature compatible with, and using
LIBRESSL_VERSION_NUMBER to identify the exact LibreSSL version.  By
polluting the OPENSSL_VERSION_NUMBER namespace we just make things
more difficult for downstream users that want to be compatible with
both OpenSSL and LibreSSL.

E.g., to check for a feature that was added in OpenSSL 1.2 but isn't
present in LibreSSL, that code now needs to be

#if OPENSSL_VERSION_NUMBER >= 1.2 && !defined(LIBRESSL_VERSION_NUMBER)

rather than simply

#if OPENSSL_VERSION_NUMBER >= 1.2

Breaking the latter just seems like making it more difficult to get
people to port their software from OpenSSL to LibreSSL.

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Bob Beck-2
The fundamental probelm with this Matthew - is that next time, if we
do this, by the next release we will
be chasing what features we have imported from 1.0.2g  and 10.2.z, and
1.0.2.qq - where does it end?
We will be continuing to add functionality in here from many sources,
and so assuming we could just keep
this as the 1.0.1g version number is completely wrong.

If we do that we will be perpetually updating this to be "close to"
whatever happens to be the orthogonal openssl.
feature set, we're screwed. We'll be doing this forever, and be in a
situation where it's as bad a what it is with
ACPI, where the only safe thing to report as is "Windows" so we don't
get screwed by the software trying to
do incompatible junk.

Now the mistake we made this go around is to not provide a way for
identifying that it is libressl. that has been corrected.



On Fri, Jul 11, 2014 at 4:56 PM, Matthew Dempsky <[hidden email]> wrote:

> On Fri, Jul 11, 2014 at 3:41 PM, Bob Beck <[hidden email]> wrote:
>> The OPENSSL_VERSION number is a guarantee for a certain version of the
>> ABI. As we dont' provide that (in fact much
>> of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use
>> the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION
>> is "bigger than 1.0.1g"'s.
>
> By that argument, we won't be ABI compatible with OpenSSL 2.0 either,
> so we shouldn't provide OPENSSL_VERSION at all.
>
> My 2c is for keeping OPENSSL_VERSION_NUMBER as the most recent OpenSSL
> version that we're *mostly* API/feature compatible with, and using
> LIBRESSL_VERSION_NUMBER to identify the exact LibreSSL version.  By
> polluting the OPENSSL_VERSION_NUMBER namespace we just make things
> more difficult for downstream users that want to be compatible with
> both OpenSSL and LibreSSL.
>
> E.g., to check for a feature that was added in OpenSSL 1.2 but isn't
> present in LibreSSL, that code now needs to be
>
> #if OPENSSL_VERSION_NUMBER >= 1.2 && !defined(LIBRESSL_VERSION_NUMBER)
>
> rather than simply
>
> #if OPENSSL_VERSION_NUMBER >= 1.2
>
> Breaking the latter just seems like making it more difficult to get
> people to port their software from OpenSSL to LibreSSL.

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Matthew Dempsky-3
On Fri, Jul 11, 2014 at 4:37 PM, Bob Beck <[hidden email]> wrote:
> The fundamental probelm with this Matthew - is that next time, if we
> do this, by the next release we will
> be chasing what features we have imported from 1.0.2g  and 10.2.z, and
> 1.0.2.qq - where does it end?

It ends whenever it stops helping portability for apps that are
currently written for OpenSSL.  We've expressly decided to ignore any
API/ABI compatibility guarantees with OpenSSL, so an OpenSSL version
number is inherently just a best effort to make things easier on
applications to transition from OpenSSL to LibreSSL.

Clang went through this same process with code that did GCC version
checks.  Today Clang still claims it's GCC 4.2, but in a separate
version it reveals it's Clang 3.5.

Existing code that only knows to check for older versions of GCC
(e.g., OpenBSD's <sys/cdefs.h>) continues work just fine with Clang,
because it picks up all of the definitions targeted towards GCC 4.2.
New code that wants to make use of features in GCC 4.7 and Clang 3.5
though needs to check for both; but even if it doesn't, if it includes
fallback for older versions of GCC it should still work okay with
Clang.

Concrete analogy: suppose LibreSSL 2.1 and OpenSSL 1.1 both add some
new feature, and an application that wants to be compatible with both
wants to make use of that feature.  How do they version check for its
availability?

Naively, it would be

#if LibreSSL >= 2.1 || OpenSSL >= 1.1

but that's going to cause the application to break when compiled with
older versions of LibreSSL.  It would actually needs to be

#if LibreSSL >= 2.1 || (!defined(LibreSSL) && OpenSSL >= 1.1)

We don't gain anything by making people need to write the latter, IMO.

Reply | Threaded
Open this post in threaded view
|

Re: cvs.openbsd.org: src

Piotr Sikora-2
In reply to this post by Bob Beck-2
Hey Bob,

> The fundamental probelm with this Matthew - is that next time, if we
> do this, by the next release we will
> be chasing what features we have imported from 1.0.2g  and 10.2.z, and
> 1.0.2.qq - where does it end?
> We will be continuing to add functionality in here from many sources,
> and so assuming we could just keep
> this as the 1.0.1g version number is completely wrong.
>
> If we do that we will be perpetually updating this to be "close to"
> whatever happens to be the orthogonal openssl.
> feature set, we're screwed. We'll be doing this forever, and be in a
> situation where it's as bad a what it is with
> ACPI, where the only safe thing to report as is "Windows" so we don't
> get screwed by the software trying to
> do incompatible junk.

I agree that chasing OPENSSL_VERSION_NUMBER is a lost cause, but keeping it
at 1.0.1g as a "common base" should work, in my opinion.

For the new features, applications would test (as they do now) for:

    #if OPENSSL_VERSION_NUMBER >= 0x10002002L

and once LibreSSL implements them (and the application wants to support it):

    #if OPENSSL_VERSION_NUMBER >= 0x10002002L \
        || LIBRESSL_VERSION_NUMBER >= 0x20001000L

instead of just breaking build, like it's happening right now.

Best regards,
Piotr Sikora

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Martijn van Duren
In reply to this post by Kent R. Spillner-2
Hello tech@,

I just saw the commit message below.
Currently I use the source functionality to determine whether I'm in my
home network or not and use it to customize sndiod_flags to redirect
sound to my main server.

Is there an alternative to dynamically change the rc.conf flags based on
my network?

At the moment my rc.conf.local looks as follow for sndiod:
if nc -z 192.168.153.4 11025 2> /dev/null; then
         sndiod_flags="-f snd@192.168.153.4/0"
fi

Sincerely,

Martijn van Duren

On 07/12/14 12:14, Robert Nagy wrote:

> CVSROOT: /cvs
> Module name: src
> Changes by: [hidden email] 2014/07/12 04:14:03
>
> Modified files:
> etc            : netstart rc rc.conf
> etc/rc.d       : rc.subr
>
> Log message:
> Make rc.conf a parsed configuration file and stop sourcing it as a shell
> script.
>  From now on rc.conf has a fixed syntax (key=val) and it is not allowed
> to add anything to it besides the supported syntax, it all going to be
> ignored.
>
> discussed with and help from deraadt@ and halex@
>

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Stuart Henderson-6
On 2014/07/12 14:04, Martijn van Duren wrote:
> Hello tech@,
>
> I just saw the commit message below.
> Currently I use the source functionality to determine whether I'm in my home
> network or not and use it to customize sndiod_flags to redirect sound to my
> main server.
>
> Is there an alternative to dynamically change the rc.conf flags based on my
> network?

Maybe sndiod_flags=NO and start sndiod from /etc/rc.local instead.

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Martijn van Duren
On 07/12/14 14:13, Stuart Henderson wrote:

> On 2014/07/12 14:04, Martijn van Duren wrote:
>> Hello tech@,
>>
>> I just saw the commit message below.
>> Currently I use the source functionality to determine whether I'm in my home
>> network or not and use it to customize sndiod_flags to redirect sound to my
>> main server.
>>
>> Is there an alternative to dynamically change the rc.conf flags based on my
>> network?
>
> Maybe sndiod_flags=NO and start sndiod from /etc/rc.local instead.
>
OK, then I'll have to live with the new limitation.

I am however curious about the rational behind this change. Does it
solve any particular problem/risk?
I seldomly use this style in my own scripts when I need to be able to
dynamically determine variables at runtime. So it might be wise to know
what hidden daemons I might be facing.

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Theo de Raadt
In reply to this post by Kent R. Spillner-2
> I am however curious about the rational behind this change. Does it
> solve any particular problem/risk?
> I seldomly use this style in my own scripts when I need to be able to
> dynamically determine variables at runtime. So it might be wise to know
> what hidden daemons I might be facing.

The rc configuration file is becoming a well-managed clean file so that
a mix of "tools" and "admins" can manage it.  Not quite at the level of
master.passwd, which is strictly controlled.  Still admin editable, but
well formed so that the future automatic tools won't screw up "scripting"
in the file.

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Guenther Niess-2
In reply to this post by Kent R. Spillner-2
The patch below should unbreak make release.

On 07/15/14 11:14, Marc Espie wrote:

> CVSROOT: /cvs
> Module name: src
> Changes by: [hidden email] 2014/07/15 03:14:50
>
> Removed files:
> etc/mtree      : BSD.local.dist
>
> Log message:
> folded back into 4.4BSD.dist
> removed to unconfuse devs
>
> okay aja, theo
>

Index: etc/Makefile
===================================================================
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.375
diff -u -p -r1.375 Makefile
--- etc/Makefile        15 Jul 2014 09:27:04 -0000      1.375
+++ etc/Makefile        15 Jul 2014 13:59:37 -0000
@@ -85,8 +85,6 @@ install-mtree:
            ${DESTDIR}${MTREEDIR}
        ${INSTALL} -c -o root -g wheel -m 444 mtree/4.4BSD.dist \
            ${DESTDIR}${MTREEDIR}
-       ${INSTALL} -c -o root -g wheel -m 444 mtree/BSD.local.dist \
-           ${DESTDIR}${MTREEDIR}
        ${INSTALL} -c -o root -g wheel -m 444 mtree/BSD.x11.dist \
            ${DESTDIR}${MTREEDIR}