Re: Why does OpenSSL own all the prefixes in the world?
On Sep 9, 2014, at 1:03 PM, Ted Byers r.ted.by...@gmail.com wrote: El 09/09/2014 20:39, Larry Bugbee bug...@seanet.com escribió: In the FWIW column Please don't mangle names by forcing C++ namespaces. Some us call OpenSSL from Python (and other dynamic languages) and depend on the C naming convention. Adding a OSSL_ prefix is fine; mangling creates huge problems. I use a number of such languages and it isn't all that hard to mix them with C++ (in sme cases, I'd extend them using C++ code, for the sake of performance). In the case of Python, for example, there is a boost library designed specifically for that purpose. From my perspective, that is not a big problem. Rather, it is just one of countless things I routinely have to deal with: just the cost of getting things done. Hi Ted, I would probably agree if I were building production systems. But because I build mostly prototypes, quick usually trumps having to deal with the complexity of C++. OpenSSL and LibTom get used a lot because they are C and super easy to call. When I want classes I build them in Python and call the appropriate OpenSSL functions. Life is much, much simpler when I can stick with Python, C, and Python's ctypes. Then again, if I were building a production app My best, Larry Cheers Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
Not so bad idea considering that any C program, with modern compilers, can be compiled as cpp with no problem. I am mixing code like this for years with no problem. Other apps, in other languages, that CAN load dynamic libraries, could take benefit of c++ to c lib technique wrapping such as suggested by other fellow here. But of course...this can be painful. Interprocess communication (between a XXX language program and a C++ SSL translator) is also a possibility. Considering stunnel is also a very good solution most of the time: why reinvent the wheel if one just need to talk SSL over TCP... Le 09/09/2014 20:42, Iñaki Baz Castillo a écrit : The (bad) idea of using C++ namespaces was just targered for those integrating OpenSSL into their own C++ projects. El 09/09/2014 20:39, Larry Bugbee bug...@seanet.com mailto:bug...@seanet.com escribió: In the FWIW column Please don't mangle names by forcing C++ namespaces. Some us call OpenSSL from Python (and other dynamic languages) and depend on the C naming convention. Adding a OSSL_ prefix is fine; mangling creates huge problems. -- Sent fm iTouch via Boxer
RE: Why does OpenSSL own all the prefixes in the world?
Not so bad idea considering that any C program, with modern compilers, can be
compiled as cpp with no problem.
That is wildly incorrect. C and C++ (which is what I assume cpp means) are
different languages.
Here's a C program that conforms to ISO 9899-1999. Try compiling it as C++.
-
#include stdlib.h
char *new(void) {return malloc(1);}
int main(void) {new(); return EXIT_SUCCESS;}
-
C++ has additional keywords, which invade the C application identifier
namespace. It has different syntax and semantics for the void keyword,
particularly in the case of function declarations. It has different semantics
for void* pointers. It has different rules for numeric-parameter promotions.
And so on.
People who think C++ is a superset of C are sadly mistaken, and programmers who
act on that assumption are dangerous.
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
Re: Why does OpenSSL own all the prefixes in the world?
Of course there are some differences,
but dealing with those is not a major issue...
And they lead C programs to be more clear, with stronger type management,
more clear function prototypes...
Nothing impossible to manage,
and that is worth managing.
not talking about much better rules and tools to cast pointers.
And I maintain that with modern compilers, and the help of syntax
checking by the compiler,
most C to C++ translation issues can be solved quickly.
By the way, it is a fact that people are already mixing C or C++
programs with C libs, or C++ ones,
and at a time, something impossible in C is possible in C++, like
namespaces.
So that C programmers would not be frustrated by switching to cpp
compilation.
For example, anything you do with pointers in C is possible the same way
in C++.
and you can still program without using any class nor any object if you
are refractory to object programming.
Relying on implicit numerical promotion is always a bad idea, whatever
the language is.
Le 10/09/2014 14:29, Michael Wojcik a écrit :
Not so bad idea considering that any C program, with modern compilers, can be
compiled as cpp with no problem.
That is wildly incorrect. C and C++ (which is what I assume cpp means) are
different languages.
Here's a C program that conforms to ISO 9899-1999. Try compiling it as C++.
-
#include stdlib.h
char *new(void) {return malloc(1);}
int main(void) {new(); return EXIT_SUCCESS;}
-
C++ has additional keywords, which invade the C application identifier
namespace. It has different syntax and semantics for the void keyword,
particularly in the case of function declarations. It has different semantics
for void* pointers. It has different rules for numeric-parameter promotions.
And so on.
People who think C++ is a superset of C are sadly mistaken, and programmers who
act on that assumption are dangerous.
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
:��IϮ��r�m
(���Z+�K �+1���x ��h���[�z�(���Z+� ��f�y����� �f���h��)z{,��
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Why does OpenSSL own all the prefixes in the world?
This is not the place to debate the relative merits of C, C++, or the chimerical monstrosity created by pretending the former is the latter. Suffice it to say that there are a number of people who do not agree with the claims you make for treating C as C++, and they are generally people who actually understand the C language. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
Re: Why does OpenSSL own all the prefixes in the world?
Pretending that the contrary is impossible and insurmoutable is just a conservative fear fud and uncertainty approach, based on trivial examples that can/should be expurged from any industrial program in a couple of minutes. Understanding C language is not as complicated as C++, and I am not of those pretending that there is deep science where there is only some poor syntax concepts in discussion, and even if I agree that comparing both is not the main subject, it is anyway in question in this prefix messtopic. I am programming in both for robotics since 20 years, and mixing the two when obligated to do so, and provided that you take care of some few differences (I mean for functional programming), it is easy to switch from C to C++ (not the contrary, of course), No need to pretend to be a C guru to make possible things appear as impossible. Le 10/09/2014 15:28, Michael Wojcik a écrit : This is not the place to debate the relative merits of C, C++, or the chimerical monstrosity created by pretending the former is the latter. Suffice it to say that there are a number of people who do not agree with the claims you make for treating C as C++, and they are generally people who actually understand the C language. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
On Wed, Sep 10, 2014 at 9:28 AM, Michael Wojcik michael.woj...@microfocus.com wrote: This is not the place to debate the relative merits of C, C++, or the chimerical monstrosity created by pretending the former is the latter. Suffice it to say that there are a number of people who do not agree with the claims you make for treating C as C++, and they are generally people who actually understand the C language. -- Well Michael, you're partly right. This isn't the place to debate the relative merits of C and C++, or any other language. But it smells a bit of extreme arrogance to suggest that those who disagree with you about the relation between C and C++ do not actually understand C. Really? You can't be serious. I have used both for decades. There is no doubt that they are different programming languages (so I don't fully disagree with you, but rather think your position is grossly over-stated). At the same time, they have so much in common that for many software engineers, C can, for practical purposes, be regarded as a useful subset of C++. This is certainly true in the suite of problem domains I usually find myself working on. But, no one would claim C IS C++, because C doesn't have templates, and thus template meta-programming, or classes, c. Even though I have been using C for decades, there are parts of the language I have never used. The same is true for C++. And, for those parts of each language that I do use, C is in fact a subset of C++ and I really do not care about the differences between the two as I do not use those parts of either language anyway. I am too busy getting production code developed, tested and deployed to spend much time worrying about such things: software that generates anywhere from hundreds of thousands of dollars to millions of dollars in revenue for the people for whom I develop the software. I am quite content to let language lawyers in academia argue about the differences between the languages (in the taxonomy of anything - natural and artificial languages, living things, academic taxonomists, there are lumpers who overemphasize similarities and splitters who overemphasize differences, and never will the two camps agree, though they DO tend to produce humorous flame wars that make all involved look foolish), but, being academics, they are not primarily focused on producing production quality software. The original question regarding C++ here involved the observation that use of C++, and specifically it's support for namespaces, may help address some, but not all, of the problems related to naming collisions. That observation is right, but it obviously will carry a cost. Whether that cost is warranted is a matter of opinion. Certainly it ought not be ruled out until all other options for solving the problem at hand have been examined and one, or a small set, of the available options have been demonstrated as providing the best solution and the least cost. It will be interesting to watch how the library evolves over the next decade. Cheers Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
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 i...@aliax.net 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 Description: OpenPGP digital signature
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-09 13:14 GMT+02:00 Michael Wojcik michael.woj...@microfocus.com: You'd have to include the standard C headers before including the OpenSSL ones, outside the namespace, so that their inclusion by the OpenSSL headers has no effect. I did that, but if a openssl header file includes standard C headers that I don't include, then the namespace declaration would affect them too, am I wrong? Mind you, I don't think it's worth the effort, for the reasons I outlined earlier. Sure, it was just a vague attempt. And indeed, lot of functions in OpenSSL are given as macros, so namespaces are of little help. Thanks a lot. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why does OpenSSL own all the prefixes in the world?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Iñaki Baz Castillo Sent: Tuesday, 09 September, 2014 09:10 To: openssl-users@openssl.org Subject: Re: Why does OpenSSL own all the prefixes in the world? 2014-09-09 13:14 GMT+02:00 Michael Wojcik michael.woj...@microfocus.com: You'd have to include the standard C headers before including the OpenSSL ones, outside the namespace, so that their inclusion by the OpenSSL headers has no effect. I did that, but if a openssl header file includes standard C headers that I don't include, then the namespace declaration would affect them too, am I wrong? It shouldn't. The C standard says that the second and subsequent inclusion of a standard header has no effect, and I believe the current C++ standard inherits that rule. All the implementations I know of (with maybe some special exceptions like Splint) implement that with inclusion guards - conditional-compilation directives around all the contents of the file. So if a standard header is included once outside any namespace, then if it's included again inside a namespace, it shouldn't declare anything in that namespace, because all its contents should be skipped. I believe namespaces don't affect macro identifiers, so the guards should work. I could be wrong about that, though. I haven't tried it myself, and I don't know the C++ standard nearly as well as the C one. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-09 17:58 GMT+02:00 Michael Wojcik michael.woj...@microfocus.com:
I did that, but if a openssl header file includes standard C headers
that I don't include, then the namespace declaration would affect them
too, am I wrong?
It shouldn't. The C standard says that the second and subsequent inclusion of
a standard header has no effect, and I believe the current C++ standard
inherits that rule.
All the implementations I know of (with maybe some special exceptions like
Splint) implement that with inclusion guards - conditional-compilation
directives around all the contents of the file.
So if a standard header is included once outside any namespace, then if it's
included again inside a namespace, it shouldn't declare anything in that
namespace, because all its contents should be skipped. I believe namespaces
don't affect macro identifiers, so the guards should work.
I could be wrong about that, though. I haven't tried it myself, and I don't
know the C++ standard nearly as well as the C one.
May be I was not clear, but what I mean is:
- Let's suppose openssl/foo.h has a #include stdlib.h.
- In myproject.h I add:
namespace myproject {
#include openssl/foo.h
}
- And then in myproject.cpp I write:
p = (char*)malloc(sizeof(char) * 100);
Would this produce the malloc not found, may be you mean
'myproject::malloc'? error?
PS: Note that I do NOT include sdtlib.h in myproject.*.
--
Iñaki Baz Castillo
i...@aliax.net
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Why does OpenSSL own all the prefixes in the world?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Iñaki Baz Castillo
Sent: Tuesday, 09 September, 2014 12:44
To: openssl-users@openssl.org
Subject: Re: Why does OpenSSL own all the prefixes in the world?
May be I was not clear, but what I mean is:
- Let's suppose openssl/foo.h has a #include stdlib.h.
- In myproject.h I add:
namespace myproject {
#include openssl/foo.h
}
- And then in myproject.cpp I write:
p = (char*)malloc(sizeof(char) * 100);
Would this produce the malloc not found, may be you mean
'myproject::malloc'? error?
PS: Note that I do NOT include sdtlib.h in myproject.*.
Yes, in this case I'd expect that error. You need to include stdlib.h outside
of any namespace before you include openssl/foo.h.
My advice would be to stick a bunch of include statements for all the standard
headers used by any openssl/*.h into a single .h file, and then include that at
the top of myproject.h and any other C++ header file that includes an OpenSSL
header.
So:
- Create openssl_c_hdrs.h which has:
#include stdlib.h
#include stdio.h
#include string.h
...
- Change myproject.h to have:
#include openssl_c_hdrs.h
namespace myproject {
#include openssl/foo.h
}
Again, I can't say for sure that will work, because I haven't tested it. But it
ought to work around this particular issue. The standard headers included by
openssl_c_hdrs.h will preempt their inclusion within the namespace by the
OpenSSL headers.
Of course, for C++ code you normally wouldn't include the C standard headers;
you'd use their C++ versions (cstdlib, etc). But this sort of thing is a
special case.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
RE: Why does OpenSSL own all the prefixes in the world?
In the FWIW column Please don't mangle names by forcing C++ namespaces.
Some us call OpenSSL from Python (and other dynamic languages) and depend on
the C naming convention. Adding a OSSL_ prefix is fine; mangling creates
huge problems.
-- Sent fm iTouch via Boxer
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Iñaki Baz Castillo
Sent: Tuesday, 09 September, 2014 12:44
To: openssl-users@openssl.org
Subject: Re: Why does OpenSSL own all the prefixes in the world?
May be I was not clear, but what I mean is:
- Let's suppose openssl/foo.h has a #include stdlib.h.
- In myproject.h I add:
namespace myproject {
#include openssl/foo.h
}
- And then in myproject.cpp I write:
p = (char*)malloc(sizeof(char) * 100);
Would this produce the malloc not found, may be you mean
'myproject::malloc'? error?
PS: Note that I do NOT include sdtlib.h in myproject.*.
Yes, in this case I'd expect that error. You need to include stdlib.h outside
of any namespace before you include openssl/foo.h.
My advice would be to stick a bunch of include statements for all the standard
headers used by any openssl/*.h into a single .h file, and then include that at
the top of myproject.h and any other C++ header file that includes an OpenSSL
header.
So:
- Create openssl_c_hdrs.h which has:
#include stdlib.h
#include stdio.h
#include string.h
...
- Change myproject.h to have:
#include openssl_c_hdrs.h
namespace myproject {
#include openssl/foo.h
}
Again, I can't say for sure that will work, because I haven't tested it. But it
ought to work around this particular issue. The standard headers included by
openssl_c_hdrs.h will preempt their inclusion within the namespace by the
OpenSSL headers.
Of course, for C++ code you normally wouldn't include the C standard headers;
you'd use their C++ versions (cstdlib, etc). But this sort of thing is a
special case.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
???H???7??m
)z{,???RǫJ?i??Lj)b????)z{,?? ??)z{,????h??^t???Ƨj^??%??
RE: Why does OpenSSL own all the prefixes in the world?
The (bad) idea of using C++ namespaces was just targered for those integrating OpenSSL into their own C++ projects. El 09/09/2014 20:39, Larry Bugbee bug...@seanet.com escribió: In the FWIW column Please don't mangle names by forcing C++ namespaces. Some us call OpenSSL from Python (and other dynamic languages) and depend on the C naming convention. Adding a OSSL_ prefix is fine; mangling creates huge problems. -- Sent fm iTouch via Boxer
Re: Why does OpenSSL own all the prefixes in the world?
On Tue, Sep 9, 2014 at 2:42 PM, Iñaki Baz Castillo i...@aliax.net wrote: The (bad) idea of using C++ namespaces was just targeted for those integrating OpenSSL into their own C++ projects. Now, I would have said that using C++ namespaces was a good idea and perhaps it might be motivation to replace the MACROs by something more useful, El 09/09/2014 20:39, Larry Bugbee bug...@seanet.com escribió: In the FWIW column Please don't mangle names by forcing C++ namespaces. Some us call OpenSSL from Python (and other dynamic languages) and depend on the C naming convention. Adding a OSSL_ prefix is fine; mangling creates huge problems. I use a number of such languages and it isn't all that hard to mix them with C++ (in sme cases, I'd extend them using C++ code, for the sake of performance). In the case of Python, for example, there is a boost library designed specifically for that purpose. From my perspective, that is not a big problem. Rather, it is just one of countless things I routinely have to deal with: just the cost of getting things done. Cheers Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-08 0:04 GMT+02:00 Kyle Hamilton aerow...@gmail.com: 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 i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-08 1:15 GMT+02:00 Pierre DELAAGE delaage.pie...@free.fr: 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 i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-08 3:52 GMT+02:00 Jakob Bohm jb-open...@wisemo.com: 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 i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
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 delaage.pie...@free.fr: 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why does OpenSSL own all the prefixes in the world?
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: rs...@jabber.me Twitter: RichSalz
RE: Why does OpenSSL own all the prefixes in the world?
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: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Kyle Hamilton Sent: Sunday, 07 September, 2014 18:04 To: openssl-users@openssl.org; 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 i...@aliax.netmailto:i...@aliax.net 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
Re: Why does OpenSSL own all the prefixes in the world?
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: rs...@jabber.me 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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
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 delaage.pie...@free.fr
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
i...@aliax.net 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
Re: Why does OpenSSL own all the prefixes in the world?
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 i...@aliax.net 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
In message
2a0efb9c05d0164e98f19bb0af3708c71d12a97...@usmbx1.msg.corp.akamai.com on Mon,
8 Sep 2014 08:57:55 -0400, Salz, Rich rs...@akamai.com 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 rich...@levitte.org
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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Why does OpenSSL own all the prefixes in the world?
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: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why does OpenSSL own all the prefixes in the world?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Richard Levitte
Sent: Monday, 08 September, 2014 10:13
To: openssl-users@openssl.org
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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-08 16:29 GMT+02:00 Salz, Rich rs...@akamai.com:
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/.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
i...@aliax.net
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
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 i...@aliax.net 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/ -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Why does OpenSSL own all the prefixes in the world?
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 i...@aliax.net 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.
Re: Why does OpenSSL own all the prefixes in the world?
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 i...@aliax.net 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
