Kristen,
Your points are all good. However, I have found the compatibility
not good with customer installed versions versus my own. One of the
problems, for example, could be that openssl compiles with a certain
type of threads, not the same as your application. Same with
semaphores and who knows what else. It could be many features like
that. It could be changes in product I have found. Also, if they
install in a different location than you, the header of your program
will not find it (which can be solved with links on the user's
system, sometimes). Sometimes the user installs a version with other
dependencies (for example I use libxml2 but not the libzip ... and
when a customer put the libzip version in, my application had problems).
So then what I was doing was putting my versions of the dynamic
libraries in my own location /usr/local/application_name/lib
And linking that way and installing that way.
But then when the security changes came ... I had to again install
something and I realized it was easier to just install the static
linked software. You also get tighter testing because it will force
you to get the latest version, compile it, link it, test it, then
install it. I do a LOT of cross-platform (AIX, Linux, OS/X, SCO,
HP/UX, Windows, etc) work and have found that I am always safer
linking exactly what I want and releasing that. I guess I feel I
have more control over quality this way.
BUT THIS IS JUST A DUMB OPINION -- most people disagree. I have
found in practice that the dream of the O/S level updates magically
making security updates work for your software is a dream that is
more nightmare than pleasant. But that is just me. There are others
who do agree, I am not alone, but I would guess a minority.
As for the export question -- if they are not allowed certain things
they are not allowed. Depending on your application, it may be
OK. So if you require the illegal export of strong encryption and
you install or ask them to install, you and they are in trouble.
If your application is, say, a credit card application -- and it is
static linked and can ONLY be used to process credit cards (and you
let them generate keys through you) you are in fact able to export
without legal complication. I export, had legal advise.
I am not sure what you mean by the GNU licensing conflict. You are
still only charging for your application, whether you static or
dynamic link. I do always include the proper copyright files and put
them in /usr/local/lib ... even though my link is static. I checked
this as well.
I will tell you that both my legal checks were cursory but I am
confident they were sufficient. If you are really worried, check
with a lawyer. On the GNU I think it is pretty much a matter of the
intent of the license anyway. If you disclose it's use, include the
proper copyright/license files, and don't charge for it, I think you are fine.
There are taste issues on this -- but you may be happier with a
static link. It will load a giga-blip faster too with static link,
and you won't even notice :-) A lot will depend on what your
software is and how much of it. We have thousands of customers. We
do credit cards which requires certification and you cannot (should
not) allow the customer to change "your" software by installing a
dynamic library. In fact, what if they built themselves their own
libraries that wrote the unencrypted text out to a file? Then they
could steal credit card numbers. BAD BAD BAD. It is a security hole
to allow dynamic libraries because you have no control on what is
really there. You cannot look at a customer or credit card auditor
and say with a straight face that you control the encryption and
there is no security leak. If you statically link something in and
certify it ... it is what is is. Under current credit card rules you
may do minor updates just by notifying them -- so if you find a
security patch that applies to your application (most don't for me)
then you download, link statically, report to everyone who needs to
know, and install your app again.
Eric
At 12:13 PM 10/28/2011, Kristen J. Webb wrote:
On 10/28/11 12:39 PM, Eric S. Eberhard wrote:
I have an easy solution I use because not only do you have the problem with
admins not having the library installed, you have the problem of
them having the
wrong version installed for something they need. Your app or theirs
won't work.
Or yours will, and they update openssl and it no longer does. And some places
with strict security policies won't let you install things like
openssl (but if
they want your app they have to install it!). I simply build the static
libraries and link them in. This means nothing need exist on the
target machine
and that you have a more stable product because you have tested against the
library version you have static linked. You could argue it makes the program
bigger and my answer is -- say what? My iPod could handle my entire business
suite and data (for disk space, not actually running) -- so who cares. I have
found this is often the easiest way to go. I also make a small
wrapper that only
builds certs from openssl and uses a different name, again making
it appear to
be my software. I also allow them to use a Web interface to my site to make a
cert and download it. Eric
Static linking is something that we looked at a while back. Some other
folks have convinced me that static linking may not the best way to go.
- You have to keep up with security updates. If you link against
the system libraries, then security vulnerabilities can be handled
at the OS level. OS vendors try hard not to break backward
compatibility, but I suppose time will tell if this will come
back to bite us ;)
- I don't have a complete answer on this yet, but it would seem
to me that dynamic linking against crypto libraries instead of
shipping those bits (static link) would make life easier from a
US export side, but I am no lawyer!
- If I am not mistaken, linking against system OpenSSL libraries
allows you to work around the GNU licensing conflict which
had me worried early on as I looked to adopting OpenSSL.
Again, I'm no lawyer!
Relying on OS configuration is more difficult, especially for Linux, as I need
to now build against many linux distro's to get things right. Thanks
to virtual environments, this is at least manageable.
At 11:09 AM 10/28/2011, Kristen J. Webb wrote:
After all my wrangling, I'm leaning towards just using client certs.
Is it a reasonable assumption that on UNIX'es these days I can
expect to find libssl.so AND the openssl command line?
If not, is it reasonable to assume that A sysadmin will
install openssl to get my app to work?
Otherwise, it would seem that something as easy and well
documented as creating a CSR could be a lot more coding...
Many thanks for all the useful comments!
Kris
On 10/27/11 7:20 AM, Michael S. Zick wrote:
On Wed October 26 2011, Kristen J. Webb wrote:
Having an app that can use certs, it
appears, is nothing compared with how to deploy it and manage
those certs ;)
A general truism not specific to "certs".
Recognizing (or implementing) a "need for trust" is one thing;
Determining (or establishing) what is to be trusted is quite another.
Consider:
Your roof leaks.
Its easy to find a contractor who claims they will fix it.
Its an entirely different matter to find one you can __trust__ to do
the job correctly and to your satisfaction.
Mike
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
--
Mr. Kristen J. Webb
Teradactyl LLC.
PHONE: 1-505-242-1091
EMAIL: kw...@teradactyl.com
VISIT: http://www.teradactyl.com
Home of the
True incremental Backup System
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
Eric S. Eberhard
(928) 567-3727 Voice
(928) 567-6122 Fax
(928) 301-7537 Cell
Vertical Integrated Computer Systems, LLC
Metropolis Support, LLC
For Metropolis support and VICS MBA Support!!!! http://www.vicsmba.com
For pictures: http://www.vicsmba.com/ourpics/index.html
(You can see why we love this state :-) )
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
--
Mr. Kristen J. Webb
Teradactyl LLC.
PHONE: 1-505-242-1091
EMAIL: kw...@teradactyl.com
VISIT: http://www.teradactyl.com
Home of the
True incremental Backup System
Eric S. Eberhard
(928) 567-3727 Voice
(928) 567-6122 Fax
(928) 301-7537 Cell
Vertical Integrated Computer Systems, LLC
Metropolis Support, LLC
For Metropolis support and VICS MBA Support!!!! http://www.vicsmba.com
For pictures: http://www.vicsmba.com/ourpics/index.html
(You can see why we love this state :-) )
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
