Re: [openssl-users] Deployment

[Viktor Dukhovni]

On Mon, Jul 16, 2018 at 08:36:47AM +, Dean Warren wrote:

> Built openssl 0.9.8za with no problems on SUSE Linux Enterprise Server.

Why would you want this particular version?  It is no longer supported,
and not even the last 0.9.8 release...

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Deployment

[Matt Caswell]

On 16/07/18 15:32, Dean Warren wrote:
> Another good question.
> 
> I believe from the information I have been provided that 0.9.8za fixes the 
> issues previously described for 0.9.8h, on SLES 11 SP1 (apparently).
> (Unless I am missing something here - highly possible?)


0.9.8za may fix some issues present in 0.9.8h but it won't fix all the
issues that have been discovered and fixed in the 4 years since it was
released.

The 0.9.8 version has been out of support by the OpenSSL project for
some years now. Individual vendors may continue to support it and
backport fixes to it - so you are better off getting the latest version
from your vendor rather than from the OpenSSL project. Note that
sometimes vendors freeze the version number, even though they are
continuing to fix security issues, i.e. just because you have 0.9.8h it
doesn't mean it has all the same issues that 0.9.8h sourced directly
from the OpenSSL project has. The vendor may have patched the issues but
maintained the version number at 0.9.8h.

I can't say anything much specifically about Suse policy, but I did find
this:

https://www.suse.com/lifecycle/

This suggests that SLES 11 is still in support until 31st March 2019
(although the current version is listed as SP4 - so you may need to
upgrade to that). This page suggests that their policy is to continue to
fix security issues during that support period:

https://www.suse.com/support/policy/

So, it seems to me, that your best bet is to upgrade to SP4 and ensure
all patches are kept up-to-date.

Note though that after 31st March 2019 you are into Long Term Service
Pack Support (which presumably you have to pay extra for).

Matt


> 
> Dean Warren 
> 
> -Original Message-
> From: openssl-users  On Behalf Of Michael 
> Wojcik
> Sent: 16 July 2018 15:27
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Deployment
> 
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
>> Behalf Of Dean Warren
>> Sent: Monday, July 16, 2018 03:32
>> To: openssl-users@openssl.org
>> Subject: Re: [openssl-users] Deployment
>>
>> Yeah that does sounds scary.
>> I will look into vendors options.
> 
> Also - why 0.9.8za? That's *ancient*. This seems like a lot of work for a 
> result of rather dubious value. What problem are you trying to solve?
> 
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
> 
> 
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> 
> SCISYS UK Limited. Registered in England and Wales No. 4373530.
> Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
>  
> Before printing, please think about the environment.
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Deployment

[Dean Warren]

Another good question.

I believe from the information I have been provided that 0.9.8za fixes the 
issues previously described for 0.9.8h, on SLES 11 SP1 (apparently).
(Unless I am missing something here - highly possible?)

Dean Warren 

-Original Message-
From: openssl-users  On Behalf Of Michael 
Wojcik
Sent: 16 July 2018 15:27
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Deployment

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
> Behalf Of Dean Warren
> Sent: Monday, July 16, 2018 03:32
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Deployment
>
> Yeah that does sounds scary.
> I will look into vendors options.

Also - why 0.9.8za? That's *ancient*. This seems like a lot of work for a 
result of rather dubious value. What problem are you trying to solve?

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



SCISYS UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
 
Before printing, please think about the environment.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Deployment

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Dean Warren
> Sent: Monday, July 16, 2018 03:32
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Deployment
>
> Yeah that does sounds scary.
> I will look into vendors options.

Also - why 0.9.8za? That's *ancient*. This seems like a lot of work for a 
result of rather dubious value. What problem are you trying to solve?

--
Michael Wojcik
Distinguished Engineer, Micro Focus


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Deployment

[Dean Warren]

Yeah that does sounds scary.
I will look into vendors options.
Thanks
Dean Warren 

-Original Message-
From: openssl-users  On Behalf Of Kyle 
Hamilton
Sent: 16 July 2018 10:26
To: openssl-users 
Subject: Re: [openssl-users] Deployment

Generally, you *really* do not want to replace the vendor-provided version.  
Vendors often alter things to be more compatible with their ABIs, which are the 
binary interfaces that other programs use to link to the vendor-provided 
libraries.

If you find you actually do want to, it's best to figure out how to get the 
source code of the vendor package you currently have installed, determine what 
patches were applied by the vendor, then apply those patches to the newer 
library version, and rebuild.  If you have a command that can build a system 
installation package from source code and maybe patches that you provide, that 
would be even better.  If you can do that, you can then install the new package 
you just compiled as an upgrade.

If you can't build a new system package, you have to figure out what files were 
installed by the vendor's openssl package, and back them up.  Then, you need to 
find the associated versions built by you, and place them by hand.

And if you can't get the source code to the system version, you're going to 
have to wing it.  On a machine that you can make mistakes on without 
inconveniencing other users, do the same thing as if you couldn't build a new 
system package.  Then, after placing everything, you would generally (on most 
Linuxes, depending how recent their ld.so package is) run 'ldconfig' to rebuild 
the symbolic links to what they should be.  But here's the scary part: you then 
need to shut the machine down, bring it back up, and attempt to connect to it 
via ssh or something.  You will need to test *every* package that you use that 
links to openssl, in case there were any ABI incompatibilities introduced by 
the vendor.
If there are any problems, you'll need to contact the vendor for an updated 
version.  This may require paying additional support fees.

Good luck!

-Kyle H

On Mon, Jul 16, 2018 at 1:36 AM, Dean Warren  wrote:
> Built openssl 0.9.8za with no problems on SUSE Linux Enterprise Server.
>
> Just followed
> https://wiki.openssl.org/index.php/Compilation_and_Installation?
>
> Works a treat - thanks.
>
>
>
> However on sudo make install the new version doesn’t replace the 
> system installed version (obviously this may be different per system).
>
>
>
> How to make sudo make install overwrite my system version?
>
> Is this a parameter within ./Configure?
>
> And/or is it also OK to just replace original bins with symbolic links 
> to new built openssl binary and library (are there others?)?
>
>
>
> Thanks in advance
>
> Dean Warren
> Solutions Architect – Space Division
>
> SCISYS UK Limited
> T:  +44 (0)117 916 5182
> F:  +44 (0)117 916 5299
> E:  dean.war...@scisys.co.uk
> http://www.scisys.co.uk
>
>
>
>
>
> SCISYS UK Limited. Registered in England and Wales No. 4373530.
> Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
>
> Before printing, please think about the environment.
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Deployment

[Kyle Hamilton]

Generally, you *really* do not want to replace the vendor-provided
version.  Vendors often alter things to be more compatible with their
ABIs, which are the binary interfaces that other programs use to link
to the vendor-provided libraries.

If you find you actually do want to, it's best to figure out how to
get the source code of the vendor package you currently have
installed, determine what patches were applied by the vendor, then
apply those patches to the newer library version, and rebuild.  If you
have a command that can build a system installation package from
source code and maybe patches that you provide, that would be even
better.  If you can do that, you can then install the new package you
just compiled as an upgrade.

If you can't build a new system package, you have to figure out what
files were installed by the vendor's openssl package, and back them
up.  Then, you need to find the associated versions built by you, and
place them by hand.

And if you can't get the source code to the system version, you're
going to have to wing it.  On a machine that you can make mistakes on
without inconveniencing other users, do the same thing as if you
couldn't build a new system package.  Then, after placing everything,
you would generally (on most Linuxes, depending how recent their ld.so
package is) run 'ldconfig' to rebuild the symbolic links to what they
should be.  But here's the scary part: you then need to shut the
machine down, bring it back up, and attempt to connect to it via ssh
or something.  You will need to test *every* package that you use that
links to openssl,
in case there were any ABI incompatibilities introduced by the vendor.
If there are any problems, you'll need to contact the vendor for an
updated version.  This may require paying additional support fees.

Good luck!

-Kyle H

On Mon, Jul 16, 2018 at 1:36 AM, Dean Warren  wrote:
> Built openssl 0.9.8za with no problems on SUSE Linux Enterprise Server.
>
> Just followed
> https://wiki.openssl.org/index.php/Compilation_and_Installation?
>
> Works a treat - thanks.
>
>
>
> However on sudo make install the new version doesn’t replace the system
> installed version (obviously this may be different per system).
>
>
>
> How to make sudo make install overwrite my system version?
>
> Is this a parameter within ./Configure?
>
> And/or is it also OK to just replace original bins with symbolic links to
> new built openssl binary and library (are there others?)?
>
>
>
> Thanks in advance
>
> Dean Warren
> Solutions Architect – Space Division
>
> SCISYS UK Limited
> T:  +44 (0)117 916 5182
> F:  +44 (0)117 916 5299
> E:  dean.war...@scisys.co.uk
> http://www.scisys.co.uk
>
>
>
>
>
> SCISYS UK Limited. Registered in England and Wales No. 4373530.
> Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
>
> Before printing, please think about the environment.
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Deployment

[Dean Warren]

Built openssl 0.9.8za with no problems on SUSE Linux Enterprise Server.
Just followed https://wiki.openssl.org/index.php/Compilation_and_Installation?
Works a treat - thanks.

However on sudo make install the new version doesn't replace the system 
installed version (obviously this may be different per system).

How to make sudo make install overwrite my system version?
Is this a parameter within ./Configure?
And/or is it also OK to just replace original bins with symbolic links to new 
built openssl binary and library (are there others?)?

Thanks in advance
Dean Warren
Solutions Architect - Space Division
SCISYS UK Limited
T:  +44 (0)117 916 5182
F:  +44 (0)117 916 5299
E:  dean.war...@scisys.co.uk
http://www.scisys.co.uk



SCISYS UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
 
Before printing, please think about the environment.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users