Re: LibreSSL 2.1.2 linking issues

2014-12-11 Thread Brent Cook
On Thu, Dec 11, 2014 at 6:41 AM, Lukas Tribus wrote: >>> Many Lolz.. Lukas you just made my day.. >>> >>> They've been misused that way, and more than once, by more than one >>> project. This is why we really want it to be just a string, and >>> strongly discourage people from using it in the

Re: LibreSSL 2.1.2 linking issues

2014-12-11 Thread Lukas Tribus
>> Many Lolz.. Lukas you just made my day.. >> >> They've been misused that way, and more than once, by more than one >> project. This is why we really want it to be just a string, and >> strongly discourage people from using it in the way it has been >> abused. >> >> ... we could always change

Re: LibreSSL 2.1.2 linking issues

2014-12-10 Thread Theo de Raadt
> >> A second reason is to prevent software from using the version number or > >> string > >> to test for features, which has been frequently misused and abused. > > > > Have strings really been misused this way? Yikes... > > > > Many Lolz.. Lukas you just made my day.. > > They've been misu

Re: LibreSSL 2.1.2 linking issues

2014-12-10 Thread Brent Cook
On Wed, Dec 10, 2014 at 6:27 PM, Stuart Henderson wrote: > On 2014/12/10 22:57, Lukas Tribus wrote: >> I get your point, but I don't believe its always that simple. Should we >> really >> exclusively care about users of the packaging systems provided by the OS, >> nobody else? > > The standard wa

Re: LibreSSL 2.1.2 linking issues

2014-12-10 Thread Stuart Henderson
On 2014/12/10 22:57, Lukas Tribus wrote: > I get your point, but I don't believe its always that simple. Should we really > exclusively care about users of the packaging systems provided by the OS, > nobody else? The standard way to handle this for build-from-source is with pkg-config. I haven't l

Re: LibreSSL 2.1.2 linking issues

2014-12-10 Thread Bob Beck
>> A second reason is to prevent software from using the version number or >> string >> to test for features, which has been frequently misused and abused. > > Have strings really been misused this way? Yikes... > Many Lolz.. Lukas you just made my day.. They've been misused that way, and mo

Re: LibreSSL 2.1.2 linking issues

2014-12-10 Thread Lukas Tribus
> Sorry if this is long-winded: Dito :) > One reason is that incrementing for sub-minor versions in the CVS source > doesn’t mean anything, since the portable release schedule is independent in > OpenBSD land. Agreed that this doesn't make much sense for CVS source, for the -portable tarballs

Re: LibreSSL 2.1.2 linking issues

2014-12-10 Thread Brent Cook
> On Dec 10, 2014, at 10:58 AM, Lukas Tribus wrote: > >>> I believe a not to be underestimated amount of applications #ifdef's >>> certain functionality of openssl out, for example NPN >>> (SSL_CTRL_SET_TLSEXT_HOSTNAME) or server preferential cipher ordering >>> (SSL_OP_CIPHER_SERVER_PREFERENCE)

Re: LibreSSL 2.1.2 linking issues

2014-12-10 Thread Lukas Tribus
>> I believe a not to be underestimated amount of applications #ifdef's >> certain functionality of openssl out, for example NPN >> (SSL_CTRL_SET_TLSEXT_HOSTNAME) or server preferential cipher ordering >> (SSL_OP_CIPHER_SERVER_PREFERENCE). > > That's rather different to checking using defines with

Re: LibreSSL 2.1.2 linking issues

2014-12-10 Thread Joel Sing
On Wed, 10 Dec 2014, Lukas Tribus wrote: > > On 2014/12/09 07:37, Brent Cook wrote: > >> If an app calls a function, it should probably check if that function > >> exists during configuration time, rather than inferring if define A > >> exists, function B and C must exist. Especially things that ar

Re: LibreSSL 2.1.2 linking issues

2014-12-09 Thread Lukas Tribus
> On 2014/12/09 07:37, Brent Cook wrote: >> If an app calls a function, it should probably check if that function >> exists during configuration time, rather than inferring if define A >> exists, function B and C must exist. Especially things that are just >> protocol constant definitions. If they

Re: LibreSSL 2.1.2 linking issues

2014-12-09 Thread Stuart Henderson
On 2014/12/09 07:37, Brent Cook wrote: > If an app calls a function, it should probably check if that function > exists during configuration time, rather than inferring if define A > exists, function B and C must exist. Especially things that are just > protocol constant definitions. If they are us

Re: LibreSSL 2.1.2 linking issues

2014-12-09 Thread Brent Cook
On Tue, Dec 9, 2014 at 6:18 AM, Stuart Henderson wrote: > On 2014/12/09 12:30, Lukas Tribus wrote: >> Hi, >> >> I'm linking haproxy (current git master) against libressl 2.1.2 >> portable on linux, but seeing 2 issues (not present in previous >> libressl 2.1.1): >> >> >> Issue number one (not sure

Re: LibreSSL 2.1.2 linking issues

2014-12-09 Thread Stuart Henderson
On 2014/12/09 12:30, Lukas Tribus wrote: > Hi, > > I'm linking haproxy (current git master) against libressl 2.1.2 > portable on linux, but seeing 2 issues (not present in previous > libressl 2.1.1): > > > Issue number one (not sure what happens here): > > include/openssl/ssl.h:503:2: error: un

LibreSSL 2.1.2 linking issues

2014-12-09 Thread Lukas Tribus
Hi, I'm linking haproxy (current git master) against libressl 2.1.2 portable on linux, but seeing 2 issues (not present in previous libressl 2.1.1): Issue number one (not sure what happens here): include/openssl/ssl.h:503:2: error: unknown type name ‘uint8_t’   uint8_t *tlsext_ecpointformatlist