openssl packaged with GS/64

> On Jul 8, 2015, at 13:15, Paul DeBruicker via Glass <[hidden email]> wrote:
>
>
>
> Hi Norm,
>
>
>
> GLASS mailing list wrote
>> Hi Paul,
>>
>>> On 7/8/2015 12:11 PM, Paul DeBruicker via Glass wrote:
>>> Hi -
>>>
>>> I noticed that 3.2.7 is shipping with an updated openssl (1.0.2b) and
>>> that openssl is prepping to release a new version Thursday
>>> (https://mta.openssl.org/pipermail/openssl-announce/2015-July/000037.html)
>>> which patches a serious vulnerability.
>>>
>>> It is my understanding that because of how the GemStone install scripts
>>> set the PATH the version of openssl that ships with GS becomes the de
>>> facto version of openssl in use on the system its installed on.  Unless
>>> you manually delete the version of openssl that ships with GS.  Is that
>>> correct?
>> Yes that is correct.  GemStone always explicitly loads the SSL libraries
>> from $GEMSTONE/lib (64 bit or $GEMSTONE/lib32 (32 bit).
>
> My concern is not so much which one GemStone uses but that you override the
> version of the binary used by the entire rest of the system.  Right now a
> user installing GemStone 3.2.6 gets openssl 1.0.2a for their entire system.
> Not just the GemStone parts.   If, prior to installing GemStone, they were
> using/following the security releases for their OS, would be 1.0.2.c.
>
>
> So the GemStone install scripts, when they set the PATH variable, are
> overriding what the OS provides to offer a version for the whole computer
> with unpatched, known vulnerabilities.
>
>
> Would it be possible to instead have the scripts test for the presence of
> openssl on the server before installing the shipped version in
> $GEMSTONE/bin?
>
> In that way the patched versions of openssl would be available for use
> independently of the GS version.
>
> check it on a computer with GemStone installed by running:
>
> which openssl
>
> to see which openssl binary is being used and then copying that path and
> running
>
> /my/path/to/openssl version
>
> to see what version of the binary is being used by things like apache and
> nginx, etc.
>
>
> That seems like dangerous and bad behavior on the part of your installer.
>
>
>
>
>
>>
>>> If that is correct, is there a better way to do this so that users of GS
>>> don't have to delete the version of openssl you ship with the product?
>> You are free to compile a newer/different version of the SSL libs and
>> replace the ones in $GEMSTONE.  We also sometimes will do this for you
>> and release just the SSL libs.  This is why we designed our usage of SSL
>> the way we did.  It is obviously impossible to synchronize our product
>> releases with OpenSSL releases.
>>
>> We always merge the latest versions of SSL into our source code
>> repository as soon as SSL is released.  How/when we will formally
>> release this SSL release is still TBD.
>>> How do others handle this?
>> Good question for the community.  I'm not sure.
>>
>> -Norm
>>>
>>> Thanks
>>>
>>> Paul
>>> _______________________________________________
>>> Glass mailing list
>
>> Glass@.gemtalksystems
>
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>> _______________________________________________
>> Glass mailing list
>
>> Glass@.gemtalksystems
>
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
>
> --
> View this message in context: http://forum.world.st/openssl-packaged-with-GS-64-tp4836609p4836630.html
> Sent from the GLASS mailing list archive at Nabble.com.
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass