# Replace OpenSSL with LibreSSL



## getopt (Jul 12, 2014)

I have installed LibreSSL http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ with no problems on RELEASE-10.0 to /usr/local/bin. But the „old“ openssl gets the execution


```
# which openssl
/usr/bin/openssl

# openssl version
OpenSSL 1.0.1e-freebsd 11 Feb 2013

# /usr/local/bin/openssl version
LibreSSL 2.0
```

What is the best practise method to disable/remove a by default installed application (not a package or port) which comes with the system installation?


----------



## fulano (Jul 12, 2014)

Try a symlink:

`mv /usr/bin/openssl /usr/bin/openssl.old`

`cd /usr/bin`

`ln -s /usr/local/bin/openssl`


----------



## bsdkeith (Jul 12, 2014)

Should that not be 
	
	



```
ln -s <what> <where>
```
 (?)


----------



## beatgammit (Jul 12, 2014)

If you don't provide `<where>`, it will default to the current directory with the same name as `<what>`. Source.


----------



## Beastie (Jul 12, 2014)

Try the new security/libressl port instead. Perhaps it will do what you want out of the box.


----------



## AnSar (Jul 12, 2014)

/etc/libmap.conf could also be useful for remapping existing binaries that are linked against the base OpenSSL shared libs.


----------



## xtaz (Jul 13, 2014)

The same thing happens with the ports version of security/openssl which I've run for years. Installed ports software usually automatically links against this version rather than the version in the base but the command line tool is after the base version in the PATH. To get around this I always just alias `openssl` to /usr/local/bin/openssl in my .bashrc with something like this:


```
alias openssl="/usr/local/bin/openssl"
```

Obviously if you're using a different shell then aliasing is going to work differently. Probably need to add appropriate commands into .profile. Alternatively you could change the PATH environment variable to place /usr/local/bin in front of /usr/bin.

On another note I'm not sure this whole LibreSSL thing is a good idea or not yet. I would have personally rather had them contribute their patches upstream to OpenSSL instead for the benefit of everyone. Now things are going to be fractured.


----------



## Cthulhux (Jul 14, 2014)

They had no choice to do so.

Now how can I use the port? Removing security/openssl and installing security/libressl breaks all applications which use SSL, telling me that libssl.so.8 couldn't be found.


----------



## wblock@ (Jul 14, 2014)

Of course.  Those applications are looking for OpenSSL.  They would have to be rebuilt, assuming that LibreSSL provides exact binary compatibility, which, at present, it does not.

At this stage, only developers should be experimenting with LibreSSL.


----------



## Cthulhux (Jul 14, 2014)

So I'd better restrict my LibreSSL experiments to my development server then.
Is there a way to batch-rebuild all ports requiring OpenSSL with LibreSSL? I tried it for a few ports but I'm sure I missed some.


----------



## wblock@ (Jul 14, 2014)

We may both regret this, but `portmaster -o security/libressl openssl` followed by `portmaster -r libressl`.  I think, untested.


----------



## Cthulhux (Jul 14, 2014)

That'd require an installed security/openssl again.

edit:
`portmaster -o security/libressl security/openssl` seems to do the trick. Thank you!


----------



## xibo (Jul 20, 2014)

The way I read ${PORTSDIR}/Mk/bsd.openssl.mk, setting WITH_OPENSSL_PORT=YES and OPENSSL_PORT=security/libressl in make.conf(5) would not only cause the installation of libressl from ports, but also the linking of any libssl/libcrypto consumer against libressl on top of that, which is more important than the monolithic binary anyway (because it's the ssl consumers that are attackable via network, rather than a non-server binary used mostly for testing and shell scripting).

Also, the libressl port installs a binary called openssl into ${PREFIX}/bin, which should be in PATH and prefered over the system paths, so you don't need to make symlinks or the like.


----------



## RalfvdEnden (Dec 23, 2014)

To use LibreSSL, you need to set OPENSSL_SHLIBVER=30 as well (besides WITH_OPENSSL_PORT and OPENSSL_PORT).

Otherwise it will use the default (which is 8 for the openssl port) and try to reinstall libressl for everyport that uses OpenSSL.


----------



## Remington (Dec 23, 2014)

Is LibreSSL going to replace OpenSSL in the near future on FreeBSD?


----------



## gkbsd (Dec 23, 2014)

Remington said:


> Is LibreSSL going to replace OpenSSL in the near future on FreeBSD?



I would be really interested by an official answer about this as well.

Regards,
Guillaume


----------



## sysfu (Mar 11, 2015)

RalfvdEnden said:


> To use LibreSSL, you need to set OPENSSL_SHLIBVER=30 as well (besides WITH_OPENSSL_PORT and OPENSSL_PORT).


I believe this needs to be incremented to OPENSSL_SHLIBVER=32 with the release of LibreSSL 2.1.4.


----------



## kpa (Mar 11, 2015)

Remington said:


> Is LibreSSL going to replace OpenSSL in the near future on FreeBSD?



Probably not in the base system. There are plans to make the base system OpenSSL libraries private and not usable for ports. This would mean ports using OpenSSL would use the either of the ports security/openssl or security/libressl by default.


----------



## Oko (Mar 11, 2015)

Remington said:


> Is LibreSSL going to replace OpenSSL in the near future on FreeBSD?


TrueOS/PC-BSD already ships with LibreSSL instead of OpenSSL.


----------



## obsigna (Mar 11, 2015)

gkbsd said:


> Remington said:
> 
> 
> > Is LibreSSL going to replace OpenSSL in the near future on FreeBSD?
> ...



The todays forums post A look at the upcoming features for 10.1.2 reveals:


> We’ve made the switchover to convert our ports to use LibreSSL by default instead of the base systems OpenSSL ...



Hopefully, I will be able to stay with OpenSSL without experiencing major hassles.


----------



## free-and-bsd (Dec 4, 2017)

Any news here?


----------



## SirDice (Dec 4, 2017)

IF (a big IF) OpenSSL is going to be replaced by LibreSSL it's going to be with 12.0-RELEASE. Not before, as that would break the ABI/API. For ports you can already switch by setting DEFAULT_VERSIONS.


----------

