APR a Safe C library?
Hi all, Not sure if this is the right place to ask or not, so sorry if it isn't. I am currently using the APR library in conjunction with the Active MQ CPP connector, so that I can produce and consume topics over an Active MQ bus. Recently I have asked to evaluate the security of our system and the components that it uses. One of those requirements is to make sure that the software is protected as best as it can be from buffer exploits, and one way of doing this is to make sure that safe C libraries are being used with C code, and that C++ code uses safe API equivalents, e.g. strncpy() to strncpy_S(). Reading the APR site, it says that you take security very seriously, so I am assuming that the library should be ok for this. I could potentially get someone to look in to the code, but I thought it would be quicker to ask first. So, any comments? Thanks in advance!
Re: Time for APR 2.0?
Am 28.08.2015 um 01:53 schrieb Noel Butler: That's why I want us to extend cmake to do the unix build as well. The biggest bitch I here from *nix/bsd system admins everywhere is cmake, the largest bitch is people know how to use --with-foo --with-bar now after decades, THEY, the people you expect to use your software, have to learn it no longer works that way, I know of multinationals change software because of cmake, I've seen a well known large international issue a policy that they will remain on old unsupported versions of mysql because they moved to cmake. autoconf et al, might be ol school, but every man, woman, and dog knows and understands it, Knows yes. Understands autoconf/m4/libtool in depth: Highly in doubt about that claim, the vast amount of cargo culted libtool/m4/configure macros floating around speaks against it. Autoconf/libtool is great when it works. But if it does not, you are in for a world of pain. CMake is different yes, and has quite a few warts of its own, but it is vastly simpler to understand and reason about than libtool/configure/etc. Regarding cmake as a solution to get rid of those dsp/dsw files: YES! Cmake provided project/nmake/make files have one issue though, which might not be obvious to someone never using cmake: Those depend on cmake for a variety of tasks (e.g. install tasks are often done by invoking some 'cmake -E' stuff and so on, via extra build tasks). So if one killed off the dsp/dsw files, it gets harder to adjust and tweak the created projects in VisualStudio, you need to fix the CMake file and recreate the project file. Which isn't that much different to the way autoconf works with configure.in etc. CMake does a few things nicer than libtool/autoconf, especially when you are NOT a linux distro builder. For example it doesn't force you to use -rpath everywhere like libtool does, can create installers/rpms etc. out of the box and has various other conveniences. But to make it really good, there should be some standard FindAPR.cmake file provided (and sent to kitware for inclusion), to make it easier for packages using apr to detect the bits, pieces and parts. Michael -- Michael Schlenker Senior Software Engineer CONTACT Software GmbH Tel.: +49 (421) 20153-80 Wiener Straße 1-3 Fax:+49 (421) 20153-41 28359 Bremen E-Mail: michael.schlen...@contact-software.com http://www.contact-software.com/ Registered office: Bremen, Germany Managing directors: Karl Heinz Zachries, Ralf Holtgrefe Court of register: Amtsgericht Bremen HRB 1321
Re: Time for APR 2.0?
On Aug 27, 2015, at 7:53 PM, Noel Butler noel.but...@ausics.net wrote: That's why I want us to extend cmake to do the unix build as well. The biggest bitch I here from *nix/bsd system admins everywhere is cmake, the largest bitch is people know how to use --with-foo --with-bar now after decades, THEY, the people you expect to use your software, have to learn it no longer works that way, I know of multinationals change software because of cmake, I've seen a well known large international issue a policy that they will remain on old unsupported versions of mysql because they moved to cmake. autoconf et al, might be ol school, but every man, woman, and dog knows and understands it, and its more than time proven, I've heard that cmake is an in thing for windows stuff (I dont use any windaz anywhere in our ops), but have you seen the stats on windows servers V *nix/bsd lately, cmake may or may not be nicer for devs, but devs rarely manage any large number of servers outside of their own build vm numbers, so I'd think twice before changing unless you keep ol school as well. I for one, consider it a PITA as well, thats my opinion anyway. Mine as well..., fwiw.
Re: Time for APR 2.0?
Am 28.08.2015 um 15:20 schrieb Michael Schlenker: Am 28.08.2015 um 01:53 schrieb Noel Butler: That's why I want us to extend cmake to do the unix build as well. The biggest bitch I here from *nix/bsd system admins everywhere is cmake, the largest bitch is people know how to use --with-foo --with-bar now after decades, THEY, the people you expect to use your software, have to learn it no longer works that way, I know of multinationals change software because of cmake, I've seen a well known large international issue a policy that they will remain on old unsupported versions of mysql because they moved to cmake. autoconf et al, might be ol school, but every man, woman, and dog knows and understands it, Knows yes. Understands autoconf/m4/libtool in depth: Highly in doubt about that claim, the vast amount of cargo culted libtool/m4/configure macros floating around speaks against it. Autoconf/libtool is great when it works. But if it does not, you are in for a world of pain. CMake is different yes, and has quite a few warts of its own, but it is vastly simpler to understand and reason about than libtool/configure/etc. Regarding cmake as a solution to get rid of those dsp/dsw files: YES! Cmake provided project/nmake/make files have one issue though, which might not be obvious to someone never using cmake: Those depend on cmake for a variety of tasks (e.g. install tasks are often done by invoking some 'cmake -E' stuff and so on, via extra build tasks). I want to strengthen this point: IMHO very similar to configure, using cmake as a generator without having cmake on the system where you run the build likely will not work. You can't just run it at release time, generate nmake or vcxproj files and the consumer only uses MSVC to do the build. The end user will need to run cmake on his system. I have seen cmake calls in the generated nmake files, but also full absolute paths to extracted source files etc. in the generated vcxproj files. So those can't be generated at release time. I'm not terribly experienced with cmake though and maybe it has a more friendly generation mode. Despite those problems, I don't know of a better way to maintain the build artefacts we need to ensure windows platform support. So if one killed off the dsp/dsw files, it gets harder to adjust and tweak the created projects in VisualStudio, you need to fix the CMake file and recreate the project file. Which isn't that much different to the way autoconf works with configure.in etc. CMake does a few things nicer than libtool/autoconf, especially when you are NOT a linux distro builder. For example it doesn't force you to use -rpath everywhere like libtool does, can create installers/rpms etc. out of the box and has various other conveniences. But to make it really good, there should be some standard FindAPR.cmake file provided (and sent to kitware for inclusion), to make it easier for packages using apr to detect the bits, pieces and parts. Rainer
Re: Time for APR 2.0?
On Aug 28, 2015 9:24 AM, Rainer Jung rainer.j...@kippdata.de wrote: Am 28.08.2015 um 15:20 schrieb Michael Schlenker: Cmake provided project/nmake/make files have one issue though, which might not be obvious to someone never using cmake: Those depend on cmake for a variety of tasks (e.g. install tasks are often done by invoking some 'cmake -E' stuff and so on, via extra build tasks). I want to strengthen this point: IMHO very similar to configure, using cmake as a generator without having cmake on the system where you run the build likely will not work. You can't just run it at release time, generate nmake or vcxproj files and the consumer only uses MSVC to do the build. The end user will need to run cmake on his system. I have seen cmake calls in the generated nmake files, but also full absolute paths to extracted source files etc. in the generated vcxproj files. So those can't be generated at release time. I'm not terribly experienced with cmake though and maybe it has a more friendly generation mode. Despite those problems, I don't know of a better way to maintain the build artefacts we need to ensure windows platform support. That's been my experience too so far with pcre. I am working on citrus bsd iconv as my first pcre scheme so I should learn a lot (this is needed to kill off apr-iconv windows support.) That said, dsp/dsw suffers the same issues. We have my fix scripts for that very reason. So I don't know that the issue will be as critical as we fear. Most of the configure time choices are to build a loadable component, and the core lib doesn't need to know which will be buildable. It didn't even support install, we have makefile.win for that, and I can't see it going away. If pcre provides a good alternative for install, great, but it is not critical. But to make it really good, there should be some standard FindAPR.cmake file provided (and sent to kitware for inclusion), to make it easier for packages using apr to detect the bits, pieces and parts. +1
Re: APR a Safe C library?
I really like the apr memory pool functions (aka arenas or regions [1]); it makes it easier to write memory-safe code. Of course, it is still the C programming language; you don't have compile-time enforced memory safety like with the Rust programming language, for instance. But these APR memory allocation functions are a big help in programming with memory safety. [1] https://en.wikipedia.org/wiki/Region-based_memory_management On Fri, Aug 28, 2015 at 5:10 PM, Wes Garland w...@page.ca wrote: It's used by Apache httpd. I think that pretty much says everything you need to know :) Sent from my iPhone On Aug 28, 2015, at 6:04, Tristan Leask tristan.le...@enghouse.com wrote: Hi all, Not sure if this is the right place to ask or not, so sorry if it isn't. I am currently using the APR library in conjunction with the Active MQ CPP connector, so that I can produce and consume topics over an Active MQ bus. Recently I have asked to evaluate the security of our system and the components that it uses. One of those requirements is to make sure that the software is protected as best as it can be from buffer exploits, and one way of doing this is to make sure that safe C libraries are being used with C code, and that C++ code uses safe API equivalents, e.g. strncpy() to strncpy_S(). Reading the APR site, it says that you take security very seriously, so I am assuming that the library should be ok for this. I could potentially get someone to look in to the code, but I thought it would be quicker to ask first. So, any comments? Thanks in advance!
Re: APR a Safe C library?
On 08/28/2015 06:04 AM, Tristan Leask wrote: Hi all, Not sure if this is the right place to ask or not, so sorry if it isn't. I am currently using the APR library in conjunction with the Active MQ CPP connector, so that I can produce and consume topics over an Active MQ bus. Recently I have asked to evaluate the security of our system and the components that it uses. One of those requirements is to make sure that the software is protected as best as it can be from buffer exploits, and one way of doing this is to make sure that safe C libraries are being used with C code, and that C++ code uses safe API equivalents, e.g. strncpy() to strncpy_S(). Reading the APR site, it says that you take security very seriously, so I am assuming that the library should be ok for this. I could potentially get someone to look in to the code, but I thought it would be quicker to ask first. So, any comments? Thanks in advance! APR uses smarter library/system APIs in many situations and by default takes action to avoid some types of vulnerabilities (e.g., file descriptor leaks). Some APIs provided by APR help the application be smarter about avoiding security issues (e.g., by providing a smarter strcpy replacement). That said, YMMV. APR doesn't generally take action to protect against the application passing bad data to APR.
Re: APR a Safe C library?
It's used by Apache httpd. I think that pretty much says everything you need to know :) Sent from my iPhone On Aug 28, 2015, at 6:04, Tristan Leask tristan.le...@enghouse.com wrote: Hi all, Not sure if this is the right place to ask or not, so sorry if it isn't. I am currently using the APR library in conjunction with the Active MQ CPP connector, so that I can produce and consume topics over an Active MQ bus. Recently I have asked to evaluate the security of our system and the components that it uses. One of those requirements is to make sure that the software is protected as best as it can be from buffer exploits, and one way of doing this is to make sure that safe C libraries are being used with C code, and that C++ code uses safe API equivalents, e.g. strncpy() to strncpy_S(). Reading the APR site, it says that you take security very seriously, so I am assuming that the library should be ok for this. I could potentially get someone to look in to the code, but I thought it would be quicker to ask first. So, any comments? Thanks in advance!
