Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] Cannot recompile OpenVPN from sources (Read 1050 times) previous topic - next topic
0 Members and 6 Guests are viewing this topic.

[SOLVED] Cannot recompile OpenVPN from sources

Decided to dive deep and recompile OpenVPN with another OpenSSL version (1.1.1t). Because the default one is crashing and segfaulting my OpenVPN for some unknown reason. And I know that version 1.1.1t works OK (from another distro).

So, I'm trying to simply:

Code: [Select]
git clone https://gitea.artixlinux.org/packagesO/openvpn.git
cd openvpn/trunk/
makepkg --nobuild --syncdeps --rmdeps

And I get this:

Code: [Select]
==> Verifying source file signatures with gpg...
    openvpn git repo ... FAILED (unknown public key 1D829EFECA562812)
==> ERROR: One or more PGP signatures could not be verified!

Why? An error in your PKGBUILD or what?

So, I'm like with two problems already: cannot recompile OpenVPN and cannot find a way to specify another version of OpenSSL instead of the default one (see the link above please).

Re: Cannot recompile OpenVPN from sources

Reply #1 –
Quote from: TheExplorer – on
Code: [Select]
==> Verifying source file signatures with gpg...
    openvpn git repo ... FAILED (unknown public key 1D829EFECA562812)
==> ERROR: One or more PGP signatures could not be verified!

Why? An error in your PKGBUILD or what?

How about:

Code: [Select]
gpg --recv-keys 1D829EFECA562812
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "

Re: Cannot recompile OpenVPN from sources

Reply #2 –
The one way to guarantee that "openssl 1.1.1" is only used would be to build "openvpn" in a chroot after modifying the dependency for "openssl" to be "openssl=1.1.1"
Please see Building in a clean chroot for more information.

Re: Cannot recompile OpenVPN from sources

Reply #3 –
Quote from: jspaces – on
The one way to guarantee that "openssl 1.1.1" is only used would be to build "openvpn" in a chroot after modifying the dependency for "openssl" to be "openssl=1.1.1"
Please see Building in a clean chroot for more information.

Thanks. Do I have to just edit the PKGBUILD or dive deep into the sources like configure.ac ? I'm new to this but learn pretty fast.

Re: Cannot recompile OpenVPN from sources

Reply #4 –
Tried to add this line to the PKGBUILD:

Code: [Select]
build() {
  mkdir "${srcdir}"/build
  cd "${srcdir}"/build

  "${srcdir}"/openvpn/configure \
    --prefix=/usr \
    --sbindir=/usr/bin \
    --enable-pkcs11 \
    --enable-plugins \
    --disable-systemd \
    --enable-x509-alt-username \
    OPENSSL_CFLAGS="-I/usr/include/openssl-1.1/openssl"
  make
}

And I get this:

Code: [Select]
configure: error: openssl check failed
==> ERROR: A failure occurred in build().
    Aborting...

What am I doing wrong?

Re: Cannot recompile OpenVPN from sources

Reply #6 –
This is what I recommended to be changed in the PKGBUILD before building in a clean chroot with only version 1.1.1 of openssl install inside it..
Code: [Select]
depends=('openssl' 'lzo' 'lz4' 'pkcs11-helper' 'libpkcs11-helper.so')
Change the openssl value to:
Code: [Select]
depends=('openssl-1.1' 'lzo' 'lz4' 'pkcs11-helper' 'libpkcs11-helper.so')

The Arch chroot wiki documentation I linked to uses arch-chroot for the procedure.
Artix has a similar version call artix-chroot which provides the same functionality.
Any Arch dev tools mentioned in Arch's wiki can usually be changed to Artix's version just swapping the arch name to artix.
Be sure to have Artix's versions of Arch's devtools installed.
Code: [Select]
# pacman -Syu artools-base artools-pkg
If you want Artix's way to build an ISO then also add "artools-iso".
One can check the names of the scripts by running "pacman -Ql artools-base" and "pacman -Ql artools-pkg".

One can try playing around with environmental exports, setting and custom library linking paths but it is full of trail and errors, a frustrating approach.
The source code does not make it easy to select a specific openssl version during the compile and linking.
Thus the clean chroot method with only the 1.1.1 version of openssl installed provides the building environment that will allow openvpn will compile and link easily without too much fuss.

Re: Cannot recompile OpenVPN from sources

Reply #7 –
Quote from: jspaces – on
This is what I recommended to be changed in the PKGBUILD before building in a clean chroot with only version 1.1.1 of openssl install inside it..

Thank you very much for your time. Ok, will try it now.

Re: Cannot recompile OpenVPN from sources

Reply #8 –
Quote from: jspaces – on
Any Arch dev tools mentioned in Arch's wiki can usually be changed to Artix's version just swapping the arch name to artix.

I see a command:

Code: [Select]
$ arch-nspawn $CHROOT/root pacman -Syu

What is Artix's version of it?

Re: Cannot recompile OpenVPN from sources

Reply #9 –
And this:

Code: [Select]
$ makechrootpkg -c -r $CHROOT

?

Re: Cannot recompile OpenVPN from sources

Reply #10 –
Artix appears to have a script for this which appears to be exactly what one wants to build in a clean chroot.
The Arch wiki appears to be not the best source now, sorry about that.
Code: [Select]
$ pacman -Ql artools-pkg
artools-pkg /usr/bin/mkchrootpkg

Usage: mkchrootpkg [options] -r <chrootdir> [--] [makepkg args]
 Run this script in a PKGBUILD dir to build a package inside a
 clean chroot. Arguments passed to this script after the
 end-of-options marker (--) will be passed to makepkg.

 The chroot dir consists of the following directories:
 <chrootdir>/{root, copy} but only "root" is required
 by default. The working copy will be created as needed

The chroot 'root' directory must be created via the following
command:
    mkchroot <chrootdir>/root base-devel

This script reads {SRC,SRCPKG,PKG,LOG}DEST, MAKEFLAGS and PACKAGER
from makepkg.conf(5), if those variables are not part of the
environment.

Default makepkg args: --syncdeps --noconfirm --log --holdver --skipinteg

Flags:
 -h         This help
 -c         Clean the chroot before building
 -d <dir>   Bind directory into build chroot as read-write
 -D <dir>   Bind directory into build chroot as read-only
 -u         Update the working copy of the chroot before building
           This is useful for rebuilds without dirtying the pristine
           chroot
 -r <dir>   The chroot dir to use
 -I <pkg>   Install a package into the working copy of the chroot
 -l <copy>  The directory to use as the working copy of the chroot
            Useful for maintaining multiple copies
            Default: sol
 -n         Run namcap on the package
 -C         Run checkpkg on the package
 -N         Disable check() function
 -T         Build in a temporary directory
 -U         Run makepkg as a specified user
The last time I looked at the artools-pkg scripts was quite a while ago and I missed this one.

Re: Cannot recompile OpenVPN from sources

Reply #11 –
The chroot method will not work for this after playing with it for most of the day.
Sorry for recommending this method.

Openssl is a key library linked to many core packages.
When one installs base-devel, system/openssl 3.0.8-1 is also installed.

Thus the only way to get a clean environment without openssl 3.0.8 is to build the complete tool-chain using openssl-1.1.
Following the Linux From Scratch type of source building maybe the easiest way to get openvpn  that uses the openssl-1.1 as a static library compiled in.
The resulting binary could then be used to run the company VPN no matter the placement with the correct permissions.

I have also tried using the configuration switches but the linking fails:
Code: [Select]
OPENSSL_CFLAGS="-I/usr/include/openssl-1.1/openssl -Wl,--enable-new-dtags,-rpath=/usr/lib/openssl-1.1/ -L/usr/lib/openssl-1.1/" \
  "${srcdir}"/openvpn/configure \
    --prefix=/opt/openvpn-ssl-1.1 \
    --sbindir=/usr/bin \
    --enable-pkcs11 \
    --enable-plugins \
    --disable-systemd \
    --enable-x509-alt-username

Re: Cannot recompile OpenVPN from sources

Reply #12 –
Quote from: jspaces – on
Thus the only way to get a clean environment without openssl 3.0.8 is to build the complete tool-chain using openssl-1.1.

I have also tried using the configuration switches but the linking fails:

Sad. Anyway, thank you VERY much for your efforts and time. I'm really sorry I made you dig all this that deep for me... Thanks a ton.

Re: Cannot recompile OpenVPN from sources

Reply #13 –
There is a package in the AUR which can provide clues on how to do this:
openvpn-openssl-1.0
One of the key lines that adapts it is this:
  export PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig
There is an openssl-1.1 in the repos, pkgconfig points the build system at the required lib versions when you have installed that alongside the regular openssl which most of the system uses.
As the Arch and AUR packages have systemd dependencies this PKGBUILD would need to be compared to the Artix one and adapted likewise. It might also be needed to build a particular version of OpenVPN to be compatible with the older openssl, I have no idea if this is the case though.

Re: Cannot recompile OpenVPN from sources

Reply #14 –
Quote from: ####### – on
There is a package in the AUR which can provide clues on how to do this:
openvpn-openssl-1.0
One of the key lines that adapts it is this:
  export PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig
There is an openssl-1.1 in the repos, pkgconfig points the build system at the required lib versions when you have installed that alongside the regular openssl which most of the system uses.
As the Arch and AUR packages have systemd dependencies this PKGBUILD would need to be compared to the Artix one and adapted likewise. It might also be needed to build a particular version of OpenVPN to be compatible with the older openssl, I have no idea if this is the case though.

Yes, trying it out now. But I get this. Dunno why:

Code: [Select]
==> Verifying source file signatures with gpg...
    openvpn git repo ... SIGNATURE NOT FOUND
==> ERROR: One or more PGP signatures could not be verified!