Why does OpenSSL own all the prefixes in the world?

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

Why does OpenSSL own all the prefixes in the world?

Iñaki Baz Castillo
Hi,

RAND_xxx
CRYPTO_xxx
ERR_xxx
ENGINE_xxx
EVP_xxx
sk_xxx
X509_xxx
BIGNUM_xxx
RSA_xxx
BN_xxx
ASN1_xxx
EC_xxx

etc etc etc.

May I understand why it was decided that OpenSSL can own all the
prefixes or "namespaces" in the world? How is it possible that OpenSSL
owns the ERR_ prefix (for example ERR_free_strings() and others)?

OpenSSL is a library. I should be able to integrate OpenSSL into my
own code and define my own prefixes without worrying about creating
conflicts with the near 200 prefixes that OpenSSL owns.


An example of a well designed C library is libuv [*], in which:

* Public API functions and structs begin with uv_.
* Private API functions begin with uv__.
* Public macros begin UV_.

That's a good design!


PS: In my project I use both openssl and libsrtp. In which of them do
you expect the following macro is defined?:

  SRTP_PROTECTION_PROFILE




[*] https://github.com/joyent/libuv/


--
Iñaki Baz Castillo
<[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Kyle Hamilton
The reason is "legacy". Eric Young was not conscious of namespace pollution when he implemented SSLeay; since then, even after the migration to the OpenSSL name and team, the focus has been more on maintaining source compatibility than in creating new interoperability opportunities.

To meet the goal of interoperability while enabling an alternate symbolic namespace, what would you suggest?

-Kyle H

On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo" <[hidden email]> wrote:
Hi,

RAND_xxx
CRYPTO_xxx
ERR_xxx
ENGINE_xxx
EVP_xxx
sk_xxx
X509_xxx
BIGNUM_xxx
RSA_xxx
BN_xxx
ASN1_xxx
EC_xxx

etc etc etc.

May I understand why it was decided that OpenSSL can own all the
prefixes or "namespaces" in the world? How is it possible that OpenSSL
owns the ERR_ prefix (for example ERR_free_strings() and others)?

OpenSSL is a library. I should be able to integrate OpenSSL into my
own code and define my own prefixes without worrying about creating
conflicts with the near 200 prefixes that OpenSSL owns.


An example of a well designed C library is libuv [*], in which:

* Public API functions and structs begin with uv_.
* Private API functions begin with uv__.
* Public macros begin UV_.

That's a good design!


PS: In my project I use both openssl and libsrtp. In which of them do
you expect the following macro is defined?:

SRTP_PROTECTION_PROFILE




[*] https://github.com/joyent/libuv/


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Pierre DELAAGE
Hmm...
Switch strongly and definitely to C++....
Not for fancy object programming, but for more practical syntaxES for things like this.

And I am an old C fan programmer...
Pierre Delaage



Le 08/09/2014 00:04, Kyle Hamilton a écrit :
The reason is "legacy". Eric Young was not conscious of namespace pollution when he implemented SSLeay; since then, even after the migration to the OpenSSL name and team, the focus has been more on maintaining source compatibility than in creating new interoperability opportunities.

To meet the goal of interoperability while enabling an alternate symbolic namespace, what would you suggest?

-Kyle H

On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo" [hidden email] wrote:
Hi,

RAND_xxx
CRYPTO_xxx
ERR_xxx
ENGINE_xxx
EVP_xxx
sk_xxx
X509_xxx
BIGNUM_xxx
RSA_xxx
BN_xxx
ASN1_xxx
EC_xxx

etc etc etc.

May I understand why it was decided that OpenSSL can own all the
prefixes or "namespaces" in the world? How is it possible that OpenSSL
owns the ERR_ prefix (for example ERR_free_strings() and others)?

OpenSSL is a library. I should be able to integrate OpenSSL into my
own code and define my own prefixes without worrying about creating
conflicts with the near 200 prefixes that OpenSSL owns.


An example of a well designed C library is libuv [*], in which:

* Public API functions and structs begin with uv_.
* Private API functions begin with uv__.
* Public macros begin UV_.

That's a good design!


PS: In my project I use both openssl and libsrtp. In which of them
do
you expect the following macro is defined?:

  SRTP_PROTECTION_PROFILE




[*] https://github.com/joyent/libuv/


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Jakob Bohm-7
And how would you do that without breaking compatibility with every
program (in C, C++ or any other language) that already uses openssl and
depends on the current API names?

Providing the API, semantics and portability of the original SSLeay
library is thesecond-most important feature of OpenSSL (right after
actually being a secure SSL/TLSimplementation when used correctly).

On 08/09/2014 01:15, Pierre DELAAGE wrote:

> Hmm...
> Switch strongly and definitely to C++....
> Not for fancy object programming, but for more practical syntaxES for
> things like this.
>
> And I am an old C fan programmer...
> Pierre Delaage
>
>
>
> Le 08/09/2014 00:04, Kyle Hamilton a écrit :
>> The reason is "legacy". Eric Young was not conscious of namespace
>> pollution when he implemented SSLeay; since then, even after the
>> migration to the OpenSSL name and team, the focus has been more on
>> maintaining source compatibility than in creating new
>> interoperability opportunities.
>>
>> To meet the goal of interoperability while enabling an alternate
>> symbolic namespace, what would you suggest?
>>
>> -Kyle H
>>
>> On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo"
>> <[hidden email]> wrote:
>>
>>     Hi,
>>
>>     RAND_xxx
>>     CRYPTO_xxx
>>     ERR_xxx
>>     ENGINE_xxx
>>     EVP_xxx
>>     sk_xxx
>>     X509_xxx
>>     BIGNUM_xxx
>>     RSA_xxx
>>     BN_xxx
>>     ASN1_xxx
>>     EC_xxx
>>
>>     etc etc etc.
>>
>>     May I understand why it was decided that OpenSSL can own all the
>>     prefixes or "namespaces" in the world? How is it possible that OpenSSL
>>     owns the ERR_ prefix (for example ERR_free_strings() and others)?
>>
>>     OpenSSL is a library. I should be able to integrate OpenSSL into my
>>     own code and define my own prefixes without worrying about creating
>>     conflicts with the near 200 prefixes that OpenSSL owns.
>>
>>
>>     An example of a well designed C library is libuv [*], in which:
>>
>>     * Public API functions and structs begin with uv_.
>>     * Private API functions begin with uv__.
>>     * Public macros begin UV_.
>>
>>     That's a good design!
>>
>>
>>     PS: In my project I use both openssl and libsrtp. In which of them
>>     do
>>     you expect the following macro is defined?:
>>
>>        SRTP_PROTECTION_PROFILE
>>
>>
>>
>>
>>     [*]https://github.com/joyent/libuv/
>>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Pierre DELAAGE
At a time or another,
of course there would be some (hopefully limited) rewrite in apps :

not necessarily complicated: I was thinking about C++ namespaces.

It is also possible to offer to apps maintainers a global "grep and
replace" script, based on "ed" or "vi" in an automated way,
to replace every BIO_xxx by, eg, OSSL_BIO_xxx in all files in some location.
Not so difficult either.

 From year to year, It would be strange that openssl is maintaining, by
huge effort, various versions of the library (I mean for any given
platform, whatever it is),
just to "avoid" that old apps be maintained themselves doing "lesser"
effort.
I do not see so big problems with that, provided that, apart from
adapting some code, people are NOT pushed to buy, to pay, to invest, to
migrate to other platform (a strategy that many OS vendors have).

If there is a switch to C++ one day, and/or a change in the API design,
there can be a kind of progressive "switching" period where two api's
coexist,
one giving wrappers/redirectors to the other, or one being built on top
of the other, encapsulating it and -later- making the other "NOT" public
and then maybe completely disappearing .

It would be interesting, in that perspective, to have some statistics
about the API functions REALLY in use in apps.
By some smart greps scripts that could be part of the openssl distrib
(so that people avoid to reinvent the wheel and all use the same tool
for such measurements).



Le 08/09/2014 03:52, Jakob Bohm a écrit :

> And how would you do that without breaking compatibility with every
> program (in C, C++ or any other language) that already uses openssl and
> depends on the current API names?
>
> Providing the API, semantics and portability of the original SSLeay
> library is thesecond-most important feature of OpenSSL (right after
> actually being a secure SSL/TLSimplementation when used correctly).
>
> On 08/09/2014 01:15, Pierre DELAAGE wrote:
>> Hmm...
>> Switch strongly and definitely to C++....
>> Not for fancy object programming, but for more practical syntaxES for
>> things like this.
>>
>> And I am an old C fan programmer...
>> Pierre Delaage
>>
>>
>>
>> Le 08/09/2014 00:04, Kyle Hamilton a écrit :
>>> The reason is "legacy". Eric Young was not conscious of namespace
>>> pollution when he implemented SSLeay; since then, even after the
>>> migration to the OpenSSL name and team, the focus has been more on
>>> maintaining source compatibility than in creating new
>>> interoperability opportunities.
>>>
>>> To meet the goal of interoperability while enabling an alternate
>>> symbolic namespace, what would you suggest?
>>>
>>> -Kyle H
>>>
>>> On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo"
>>> <[hidden email]> wrote:
>>>
>>>     Hi,
>>>
>>>     RAND_xxx
>>>     CRYPTO_xxx
>>>     ERR_xxx
>>>     ENGINE_xxx
>>>     EVP_xxx
>>>     sk_xxx
>>>     X509_xxx
>>>     BIGNUM_xxx
>>>     RSA_xxx
>>>     BN_xxx
>>>     ASN1_xxx
>>>     EC_xxx
>>>
>>>     etc etc etc.
>>>
>>>     May I understand why it was decided that OpenSSL can own all the
>>>     prefixes or "namespaces" in the world? How is it possible that
>>> OpenSSL
>>>     owns the ERR_ prefix (for example ERR_free_strings() and others)?
>>>
>>>     OpenSSL is a library. I should be able to integrate OpenSSL into my
>>>     own code and define my own prefixes without worrying about creating
>>>     conflicts with the near 200 prefixes that OpenSSL owns.
>>>
>>>
>>>     An example of a well designed C library is libuv [*], in which:
>>>
>>>     * Public API functions and structs begin with uv_.
>>>     * Private API functions begin with uv__.
>>>     * Public macros begin UV_.
>>>
>>>     That's a good design!
>>>
>>>
>>>     PS: In my project I use both openssl and libsrtp. In which of them
>>>     do
>>>     you expect the following macro is defined?:
>>>
>>>        SRTP_PROTECTION_PROFILE
>>>
>>>
>>>
>>>
>>>     [*]https://github.com/joyent/libuv/
>>>
>
> Enjoy
>
> Jakob

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Jeffrey Walton-3
In reply to this post by Pierre DELAAGE
On Sun, Sep 7, 2014 at 7:15 PM, Pierre DELAAGE <[hidden email]> wrote:
> Hmm...
> Switch strongly and definitely to C++....
> Not for fancy object programming, but for more practical syntaxES for things
> like this.
>
> And I am an old C fan programmer...
+1.

C really needs namespaces to avoid collisions and try/finally to
ensure cleanup (cleanup via the finally block).

Jeff

> Le 08/09/2014 00:04, Kyle Hamilton a écrit :
>
> The reason is "legacy". Eric Young was not conscious of namespace pollution
> when he implemented SSLeay; since then, even after the migration to the
> OpenSSL name and team, the focus has been more on maintaining source
> compatibility than in creating new interoperability opportunities.
>
> To meet the goal of interoperability while enabling an alternate symbolic
> namespace, what would you suggest?
>
> -Kyle H
>
> On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo" <[hidden email]>
> wrote:
>>
>> Hi,
>>
>> RAND_xxx
>> CRYPTO_xxx
>> ERR_xxx
>> ENGINE_xxx
>> EVP_xxx
>> sk_xxx
>> X509_xxx
>> BIGNUM_xxx
>> RSA_xxx
>> BN_xxx
>> ASN1_xxx
>> EC_xxx
>>
>> etc etc etc.
>>
>> May I understand why it was decided that OpenSSL can own all the
>> prefixes or "namespaces" in the world? How is it possible that OpenSSL
>> owns the ERR_ prefix (for example ERR_free_strings() and others)?
>>
>> OpenSSL is a library. I should be able to integrate OpenSSL into my
>> own code and define my own prefixes without worrying about creating
>> conflicts with the near 200 prefixes that OpenSSL owns.
>>
>>
>> An example of a well designed C library is libuv [*], in which:
>>
>> * Public API functions and structs begin with uv_.
>> * Private API functions begin with uv__.
>> * Public macros begin UV_.
>>
>> That's a good design!
>>
>>
>> PS: In my project I use both openssl and libsrtp. In which of them
>> do
>> you expect the following macro is defined?:
>>
>>   SRTP_PROTECTION_PROFILE
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Iñaki Baz Castillo
In reply to this post by Kyle Hamilton
2014-09-08 0:04 GMT+02:00 Kyle Hamilton <[hidden email]>:
> To meet the goal of interoperability while enabling an alternate symbolic
> namespace, what would you suggest?

Not a big expert in these subjects, but a workaround coming to my mind
is the following:

- Prefix ALL the OpenSSL symbols with the "OPENSSL_" prefix.

- Include a m4 replacement in the whole source code of openssl with a
compiler --enable-global-prefix option to enable or disable it. This
is, when disabled the "OPENSSL_" prefix becomes an empty string and
nothing changes.

- By default the compiler option is disabled, but the project
announces this feature and encourages people to enable it and update
their projects.

- At some time the option becomes enabled by default.



--
Iñaki Baz Castillo
<[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Iñaki Baz Castillo
In reply to this post by Pierre DELAAGE
2014-09-08 1:15 GMT+02:00 Pierre DELAAGE <[hidden email]>:
> Switch strongly and definitely to C++....
> Not for fancy object programming, but for more practical syntaxES for things
> like this.

I do code in C++, but I need some C libraries. Regardless my C++ code
is properly "namespaced" I don't like to see so many global C symbols
in it. As I said before, in my case I integrate openssl and libsrtp C
libraries into my C++ project. It 's annoying for me to see that the
macro SRTP_PROTECTION_PROFILE (which I need in my project) is defined
by openssl rather than libsrtp.


--
Iñaki Baz Castillo
<[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Iñaki Baz Castillo
In reply to this post by Jakob Bohm-7
2014-09-08 3:52 GMT+02:00 Jakob Bohm <[hidden email]>:
> And how would you do that without breaking compatibility with every
> program (in C, C++ or any other language) that already uses openssl and
> depends on the current API names?

That's the show-stopper rationale. I expect that old projects relying
on OpenSSL should be adapted at some time, otherwise OpenSSL may
provide backward compatibility updates (as it does now). But at some
point bugs must be fixed and, IMHO, the namespace/prefix pollution of
OpenSSL is a bug.


--
Iñaki Baz Castillo
<[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Pierre DELAAGE
In reply to this post by Iñaki Baz Castillo
There seems to be some misunderstanding :
My original answer was not directed to you, but to Kyle who was asking
for suggestions to solve your pb.

My suggestion is indeed that openssl lib switch to C++, at least for
namespace usage.
that will solve your problem with very limited -or no- impact on other apps.




Le 08/09/2014 14:13, Iñaki Baz Castillo a écrit :

> 2014-09-08 1:15 GMT+02:00 Pierre DELAAGE <[hidden email]>:
>> Switch strongly and definitely to C++....
>> Not for fancy object programming, but for more practical syntaxES for things
>> like this.
> I do code in C++, but I need some C libraries. Regardless my C++ code
> is properly "namespaced" I don't like to see so many global C symbols
> in it. As I said before, in my case I integrate openssl and libsrtp C
> libraries into my C++ project. It 's annoying for me to see that the
> macro SRTP_PROTECTION_PROFILE (which I need in my project) is defined
> by openssl rather than libsrtp.
>
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Why does OpenSSL own all the prefixes in the world?

Salz, Rich
> My suggestion is indeed that openssl lib switch to C++, at least for
> namespace usage.

That would be nice to have.  But C++ classes are like opinions -- everyone has one, nobody wants to use anyone else's. :)

I'd be surprised if OpenSSL started work on this, but I'd encourage interested folks to work on it.

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [hidden email] Twitter: RichSalz

:��I"Ϯ��r�m���� (���Z+�K�+����1���x ��h���[�z�(���Z+� ��f�y������f���h��)z{,���
Reply | Threaded
Open this post in threaded view
|

RE: Why does OpenSSL own all the prefixes in the world?

Michael Wojcik
In reply to this post by Kyle Hamilton

While OpenSSL's namespace polution is certainly a problem - and a problem that was (in general) widely discussed in the C programming community at least as far back as the late 1980s - it's worth noting that it's a widespread issue that affects pretty much all languages of C's generation and earlier, and many application libraries.

 

For example, SGI's original GL library contained external identifiers like "c3d", which clearly stomped all over the namespace with unexpected collisions. Even today's OpenGL 4, which uses a "gl" prefix for some identifiers, has things like "any" - conceivably something an application would use.

 

Of course there are historical reasons, chiefly to do with limited resources and concommittant limitations in OS tooling. The original C standard (ISO9989-1990) only required implementations to recognize 31 significant characters in an internal identifier - which certainly limits the scope for namespace prefixes - and only *6* characters for an external identifier, which all but rules them out. (The implementation can also treat external identifiers as case-insensitive for linking purposes.)

 

There is no good solution to this. m4 preprocessing is not available (by default) on all OpenSSL platforms, and is fraught with complications, as is any other preprocessing solution: it complicates debugging, for example, and has to handle various complicated cases such as an apparent or actual identifier in quoted strings, macro expansions, and the like. Implementing an optional namespace using C preprocessor tricks such as token-pasting is an infeasible effort and similarly fraught. Moving to C++ breaks binary compatibility (due to name-mangling, etc), requires a new build system, likely breaks some supported platforms, and runs the risk of introducing failures due to the many differences between C and C++ - and it does nothing for macro names. (In general, compiling C as C++ is a Bad Idea, despite the claims of C++ proponents.)

 

What *is* feasible is wrapping OpenSSL in a library that provides the functionality your application needs, and imposes the namespace protections you want (along with any enhanced functionality, etc), while hiding OpenSSL's symbols (by not exporting the external linkage symbols and not exposing the macros to the application). That's what we do. Few applications will use all, or even most, of OpenSSL's public functionality directly anyway.

 

Michael Wojcik
Technology Specialist, Micro Focus

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kyle Hamilton
Sent: Sunday, 07 September, 2014 18:04
To: [hidden email]; Iñaki Baz Castillo
Subject: Re: Why does OpenSSL own all the prefixes in the world?

 

The reason is "legacy". Eric Young was not conscious of namespace pollution when he implemented SSLeay; since then, even after the migration to the OpenSSL name and team, the focus has been more on maintaining source compatibility than in creating new interoperability opportunities.

To meet the goal of interoperability while enabling an alternate symbolic namespace, what would you suggest?

-Kyle H

On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo" <[hidden email]> wrote:

Hi,

RAND_xxx
CRYPTO_xxx
ERR_xxx
ENGINE_xxx
EVP_xxx
sk_xxx
X509_xxx
BIGNUM_xxx
RSA_xxx
BN_xxx
ASN1_xxx
EC_xxx

etc etc etc.

May I understand why it was decided that OpenSSL can own all the
prefixes or "namespaces" in the world? How is it possible that OpenSSL
owns the ERR_ prefix (for example ERR_free_strings() and others)?

OpenSSL is a library. I should be able to integrate OpenSSL into my
own code and define my own prefixes without worrying about creating
conflicts with the near 200 prefixes that OpenSSL owns.


An example of a well designed C library is libuv [*], in which:

* Public API functions and structs begin with uv_.
* Private API functions begin with uv__.
* Public macros begin UV_.

That's a good design!


PS: In my project I use both openssl and libsrtp. In which of t!
 hem
do
you expect the following macro is defined?:

  SRTP_PROTECTION_PROFILE




[*] https://github.com/joyent/libuv/


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



This message has been scanned for malware by Websense. www.websense.com

Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Pierre DELAAGE
In reply to this post by Salz, Rich
This is why I just mentioned "namespaces"...

Le 08/09/2014 14:57, Salz, Rich a écrit :

>> My suggestion is indeed that openssl lib switch to C++, at least for
>> namespace usage.
> That would be nice to have.  But C++ classes are like opinions -- everyone has one, nobody wants to use anyone else's. :)
>
> I'd be surprised if OpenSSL started work on this, but I'd encourage interested folks to work on it.
>
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge MA
> IM: [hidden email] Twitter: RichSalz
>
> :��I"Ϯ��r�m���� (���Z+�K�+����1���x ��h���[�z�(���Z+� ��f�y������f���h��)z{,��

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Kyle Hamilton
In reply to this post by Pierre DELAAGE
If all you want is C++ namespaces,could you you wrap the #include lines for OpenSSL in a namespace declaration? (I am not a C++ guy, I honestly don't know where problems would exist... except the namespaces don't do anything for #define, I think?)

namespace openssl {
#include <ssl/whatever.h>
};

Another alternative might be to not mix code that relies on defined symbols from one library in the same source file as one which requires a different library with conflicting definitions. This would require passing context structs to functions in different source files, with those functions doing what needed to happen at that moment using the facilities available to that source file.

A bigger problem is that it would necessarily change the ABI to dictate that the symbols in the linked library cannot be linked as extern "C".

Perhaps a compatibility library that forwards old-API calls to a namespaced library could work... but the problem there is that there are platforms still in use that likely have only limited C++ support. (Such as Amiga and OS/2.)

It's not an easy problem to address, and every option has compromises.

-Kyle H

On September 7, 2014 9:44:44 PM PST, Pierre DELAAGE <[hidden email]> wrote:
At a time or another,
of course there would be some (hopefully limited) rewrite in apps :

not necessarily complicated: I was thinking about C++ namespaces.

It is also possible to offer to apps maintainers a global "grep and
replace" script, based on "ed" or "vi" in an automated way,
to replace every BIO_xxx by, eg, OSSL_BIO_xxx in all files in some location.
Not so difficult either.

From year to year, It would be strange that openssl is maintaining, by
huge effort, various versions of the library (I mean for any given
platform, whatever it is),
just to "avoid" that old apps be maintained themselves doing "lesser"
effort.
I do not see so big problems with that, provided that, apart from
adapting some code, people are NOT pushed to buy, to pay, to invest, to
migrate to other platform (a strategy that many OS vendors have).

If there is a switch to C++ one day, and/or a change in the API design,
there can be a kind of progressive "switching" period where two api's
coexist,
one giving wrappers/redirectors to the other, or one being built on top
of the other, encapsulating it and -later- making the other "NOT" public
and then maybe completely disappearing .

It would be interesting, in that perspective, to have some statistics
about the API functions REALLY in use in apps.
By some smart greps scripts that could be part of the openssl distrib
(so that people avoid to reinvent the wheel and all use the same tool
for such measurements).



Le 08/09/2014 03:52, Jakob Bohm a écrit :
And how would you do that without breaking compatibility with every
program (in C, C++ or any other language) that already uses openssl and
depends on the current API names?

Providing the API, semantics and portability of the original SSLeay
library is thesecond-most important feature of OpenSSL (right after
actually being a secure SSL/TLSimplementation when used correctly).

On 08/09/2014 01:15, Pierre DELAAGE wrote:
Hmm...
Switch strongly and definitely to C++....
Not for fancy object programming, but for more practical syntaxES for
things like this.

And I am an old C fan programmer...
Pierre Delaage



Le 08/09/2014 00:04, Kyle Hamilton a écrit :
The reason is "legacy". Eric Young was not conscious of namespace
pollution when he implemented SSLeay; since then, even after the
migration to the OpenSSL name and team, the focus has been more on
maintaining source compatibility than in creating new
interoperability opportunities.

To meet the goal of interoperability while enabling an alternate
symbolic namespace, what would you suggest?

-Kyle H

On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo"
<[hidden email]> wrote:

Hi,

RAND_xxx
CRYPTO_xxx
ERR_xxx
ENGINE_xxx
EVP_xxx
sk_xxx
X509_xxx
BIGNUM_xxx
RSA_xxx
BN_xxx
ASN1_xxx
EC_xxx

etc etc etc.

May I understand why it was decided that OpenSSL can own all the
prefixes or "namespaces" in the world? How is it possible that
OpenSSL
owns the ERR_ prefix (for example ERR_free_strings() and others)?

OpenSSL is a library. I should be able to integrate OpenSSL into my
own code and define my own prefixes without worrying about creating
conflicts with the near 200 prefixes that OpenSSL owns.


An example of a well designed C library is libuv [*], in which:

* Public API functions and structs begin with uv_.
* Private API functions begin with uv__.
* Public macros begin UV_.

That's a good design!


PS: In my project I use both openssl and libsrtp. In which of them
do
you expect the following macro is defined?:

SRTP_PROTECTION_PROFILE




[*]https://github.com/joyent/libuv/


Enjoy

Jakob



OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Pierre DELAAGE
In reply to this post by Jakob Bohm-7
"Breaking compatibilty" with old apps will occur at a time :
dixit the roadmap :
"Review and revise the public API with a view to reducing complexity
(Timescale: Within one year)"
I suppose that reducing complexity will lead to some rewrites,
elimination/merging some functions...

So it will be the right time to bring some improvements such as C++
namespaces support,
or even macro renaming,
and "breaking binary compatibility" is not really a so big issue :
at a time, if something is rewritten with efficiency and simplicity in
mind, and robustness,
it has to be promoted, pushed to replace past versions.

and binary compatibility is "already" an issue : this is why there are
so many version of openssl,
too many to my mind, so that smart resources of the team are dispersed
to redo and redo again (backporting or forward porting) all the time the
same work.

Anyway, on the short term, for an app maintainer : it is a fact that a
solution to the prefixes mess can be to encapsulate openssl in a custom
lib, hiding anything from the original lib to the external world.

Pierre







Le 08/09/2014 03:52, Jakob Bohm a écrit :

> And how would you do that without breaking compatibility with every
> program (in C, C++ or any other language) that already uses openssl and
> depends on the current API names?
>
> Providing the API, semantics and portability of the original SSLeay
> library is thesecond-most important feature of OpenSSL (right after
> actually being a secure SSL/TLSimplementation when used correctly).
>
> On 08/09/2014 01:15, Pierre DELAAGE wrote:
>> Hmm...
>> Switch strongly and definitely to C++....
>> Not for fancy object programming, but for more practical syntaxES for
>> things like this.
>>
>> And I am an old C fan programmer...
>> Pierre Delaage
>>
>>
>>
>> Le 08/09/2014 00:04, Kyle Hamilton a écrit :
>>> The reason is "legacy". Eric Young was not conscious of namespace
>>> pollution when he implemented SSLeay; since then, even after the
>>> migration to the OpenSSL name and team, the focus has been more on
>>> maintaining source compatibility than in creating new
>>> interoperability opportunities.
>>>
>>> To meet the goal of interoperability while enabling an alternate
>>> symbolic namespace, what would you suggest?
>>>
>>> -Kyle H
>>>
>>> On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo"
>>> <[hidden email]> wrote:
>>>
>>>     Hi,
>>>
>>>     RAND_xxx
>>>     CRYPTO_xxx
>>>     ERR_xxx
>>>     ENGINE_xxx
>>>     EVP_xxx
>>>     sk_xxx
>>>     X509_xxx
>>>     BIGNUM_xxx
>>>     RSA_xxx
>>>     BN_xxx
>>>     ASN1_xxx
>>>     EC_xxx
>>>
>>>     etc etc etc.
>>>
>>>     May I understand why it was decided that OpenSSL can own all the
>>>     prefixes or "namespaces" in the world? How is it possible that
>>> OpenSSL
>>>     owns the ERR_ prefix (for example ERR_free_strings() and others)?
>>>
>>>     OpenSSL is a library. I should be able to integrate OpenSSL into my
>>>     own code and define my own prefixes without worrying about creating
>>>     conflicts with the near 200 prefixes that OpenSSL owns.
>>>
>>>
>>>     An example of a well designed C library is libuv [*], in which:
>>>
>>>     * Public API functions and structs begin with uv_.
>>>     * Private API functions begin with uv__.
>>>     * Public macros begin UV_.
>>>
>>>     That's a good design!
>>>
>>>
>>>     PS: In my project I use both openssl and libsrtp. In which of them
>>>     do
>>>     you expect the following macro is defined?:
>>>
>>>        SRTP_PROTECTION_PROFILE
>>>
>>>
>>>
>>>
>>>     [*]https://github.com/joyent/libuv/
>>>
>
> Enjoy
>
> Jakob

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Richard Levitte - VMS Whacker
In reply to this post by Salz, Rich
In message <[hidden email]> on Mon, 8 Sep 2014 08:57:55 -0400, "Salz, Rich" <[hidden email]> said:

rsalz> > My suggestion is indeed that openssl lib switch to C++, at least for
rsalz> > namespace usage.
rsalz>
rsalz> That would be nice to have.  But C++ classes are like opinions -- everyone has one, nobody wants to use anyone else's. :)
rsalz>
rsalz> I'd be surprised if OpenSSL started work on this, but I'd encourage interested folks to work on it.

Nothing really stops us from creating a C++ namespace.  After all, we
do have the following construct in quite a number if not all exported
header files:

    #ifdef  __cplusplus
    extern "C" {
    #endif

    /* yada yada yada */

    #ifdef  __cplusplus
    }
    #endif

What's stopping us from specifying a namespace in there, technically
speaking?  I mean, except for backward compatibility (people will
suddenly HAVE to have a line saying "using namespace openssl;" or
something like that).

Cheers,
Richard

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Why does OpenSSL own all the prefixes in the world?

Salz, Rich
The extern "C" makes it difficult to put things into a namespace.  You'd either have to write class declarations that used NO public openssl header files in their public declaration, or we'd have to change the extern "C" wrappers to be something like
        #if defined(__cplusplus) && !defined(OPENSSL_NAMESPACED_API)


--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [hidden email] Twitter: RichSalz

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Why does OpenSSL own all the prefixes in the world?

Michael Wojcik
In reply to this post by Richard Levitte - VMS Whacker
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Richard Levitte
> Sent: Monday, 08 September, 2014 10:13
> To: [hidden email]
>
> Nothing really stops us from creating a C++ namespace.  After all, we
> do have the following construct in quite a number if not all exported
> header files:
>
>     #ifdef  __cplusplus
>     extern "C" {
>     #endif
>
>     /* yada yada yada */
>
>     #ifdef  __cplusplus
>     }
>     #endif
>
> What's stopping us from specifying a namespace in there, technically
> speaking?  I mean, except for backward compatibility (people will
> suddenly HAVE to have a line saying "using namespace openssl;" or
> something like that).

Since all the OpenSSL declarations are in an extern-C block, identifier names aren't mangled, so the namespace has no effect on external visibility. And namespaces don't affect macro names. So there's little benefit - it'd be a purely lexical change that only affects how OpenSSL functions are named within C++ translation units. It doesn't help with macro or external-symbol identifier collisions.

And anyone who wants this can simply include the OpenSSL headers within a namespace declaration.

--
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Iñaki Baz Castillo
In reply to this post by Salz, Rich
2014-09-08 16:29 GMT+02:00 Salz, Rich <[hidden email]>:
> The extern "C" makes it difficult to put things into a namespace.  You'd either have to write class declarations that used NO public openssl header files in their public declaration, or we'd have to change the extern "C" wrappers to be something like
>         #if defined(__cplusplus) && !defined(OPENSSL_NAMESPACED_API)


I've tried the "namespace openssl {  #include <openssl/xxxx.h> }
approach and it has been terrible. I've ended with compiler error
messages like:

  openssl::malloc not found

It makes sense given that the namespace is also affecting to any other
include within the openssl header file.

--
Iñaki Baz Castillo
<[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why does OpenSSL own all the prefixes in the world?

Benny Baumann
In reply to this post by Jakob Bohm-7
What about introducing a openssl_deprecated.h which sole purpose is to
throw in a bunch of defines that map ERR_old_style_name
OPENSSL_ERR_new_style_name.

To make an old-style codebase compatiblae the only thing to add would be
either including openssl_deprecated.h or set a macro on the command line
that does so from within the new-style headers (maybe on by default via
the configure).

And BTW: C++ won't hurt legibility of the source: using some scoped
pointers you can cleanup most error paths to become just "return
OPENSSL_ERR_new_style_error_name.

Regards,
BenBE.

Am 08.09.2014 03:52, schrieb Jakob Bohm:

> And how would you do that without breaking compatibility with every
> program (in C, C++ or any other language) that already uses openssl and
> depends on the current API names?
>
> Providing the API, semantics and portability of the original SSLeay
> library is thesecond-most important feature of OpenSSL (right after
> actually being a secure SSL/TLSimplementation when used correctly).
>
> On 08/09/2014 01:15, Pierre DELAAGE wrote:
>> Hmm...
>> Switch strongly and definitely to C++....
>> Not for fancy object programming, but for more practical syntaxES for
>> things like this.
>>
>> And I am an old C fan programmer...
>> Pierre Delaage
>>
>>
>>
>> Le 08/09/2014 00:04, Kyle Hamilton a écrit :
>>> The reason is "legacy". Eric Young was not conscious of namespace
>>> pollution when he implemented SSLeay; since then, even after the
>>> migration to the OpenSSL name and team, the focus has been more on
>>> maintaining source compatibility than in creating new
>>> interoperability opportunities.
>>>
>>> To meet the goal of interoperability while enabling an alternate
>>> symbolic namespace, what would you suggest?
>>>
>>> -Kyle H
>>>
>>> On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo"
>>> <[hidden email]> wrote:
>>>
>>>     Hi,
>>>
>>>     RAND_xxx
>>>     CRYPTO_xxx
>>>     ERR_xxx
>>>     ENGINE_xxx
>>>     EVP_xxx
>>>     sk_xxx
>>>     X509_xxx
>>>     BIGNUM_xxx
>>>     RSA_xxx
>>>     BN_xxx
>>>     ASN1_xxx
>>>     EC_xxx
>>>
>>>     etc etc etc.
>>>
>>>     May I understand why it was decided that OpenSSL can own all the
>>>     prefixes or "namespaces" in the world? How is it possible that
>>> OpenSSL
>>>     owns the ERR_ prefix (for example ERR_free_strings() and others)?
>>>
>>>     OpenSSL is a library. I should be able to integrate OpenSSL into my
>>>     own code and define my own prefixes without worrying about creating
>>>     conflicts with the near 200 prefixes that OpenSSL owns.
>>>
>>>
>>>     An example of a well designed C library is libuv [*], in which:
>>>
>>>     * Public API functions and structs begin with uv_.
>>>     * Private API functions begin with uv__.
>>>     * Public macros begin UV_.
>>>
>>>     That's a good design!
>>>
>>>
>>>     PS: In my project I use both openssl and libsrtp. In which of them
>>>     do
>>>     you expect the following macro is defined?:
>>>
>>>        SRTP_PROTECTION_PROFILE
>>>
>>>
>>>
>>>
>>>     [*]https://github.com/joyent/libuv/
>>>
>
> Enjoy
>
> Jakob


signature.asc (853 bytes) Download Attachment
12