On 3/19/2012 7:50 AM, grarpamp wrote:
Since OpenSSL 0.9.8 is still in widespread use it will still be
maintained for some time yet.
I think part of this is may due to the new 1.x.x releases not
being able to compile on older releases of operating systems.
Perhaps a short round of effort in resolving that would allow
people to move forward?
Another issue is that 0.9.8 has been incorporated into
various distributions that have themselves been declared as
"long term support" releases, meaning that those
distributions and their use of 0.9.8 will persist for some
time to come.

A third issue is that currently, 0.9.8 is the only OpenSSL
release to support a FIPS certified configuration, while the
upcoming 2.0 FIPS module will add that feature to 1.0.1 as
well, the nature of government work will be keeping
0.9.8+FIPS 1.2 around for years to come.

Should there be developed a customary formal policy on this
as many others now do? Ie: date of release plus n amount of time
Such policies, as spearheaded by Microsoft are a bad idea.
As a bare minimum, the date to count from should be the
date of the superseding release, not the date of the
original release, as projects that need X years of future
support might begin at any time during the upstream (in
this case OpenSSL) release cycle.   If upstream takes an
unpredictable X years between two releases, those X years
should not be deducted from the time that users can rely
on security updates for whatever was the current release
when they downloaded it.

Also, there was a thread on here not long ago about
how to compile openssl fully statically both with and
without zlib. I don't think anyone really happened to
address that well. What would be required to request
further consideration of that thread?
I am interested in that as well.  There are many good
reasons to link openssl statically rather than as a
dynamic library.  On platforms that support dynamic
libraries there are equally good reasons to link
openssl statically into a plugin-style dynamic library
whose primary functionality is something else.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, 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                    [email protected]
Automated List Manager                           [email protected]

Reply via email to