Package Details: openswan 3.0.0-1

Git Clone URL: https://aur.archlinux.org/openswan.git (read-only, click to copy)
Package Base: openswan
Description: Open Source implementation of IPsec for Linux
Upstream URL: https://www.openswan.org
Licenses: GPL, custom
Conflicts: ipsec-tools, strongswan
Submitter: Allan
Maintainer: severach
Last Packager: severach
Votes: 144
Popularity: 0.000233
First Submitted: 2009-11-07 14:39 (UTC)
Last Updated: 2025-11-28 04:23 (UTC)

Dependencies (5)

Required by (2)

Sources (2)

Latest Comments

1 2 3 4 5 6 .. 9 Next › Last »

severach commented on 2025-11-28 04:24 (UTC)

@Torxed: Should build now with gcc15.

Torxed commented on 2025-09-08 12:32 (UTC)

Not sure fully if it's a local issue, but it feels like a change/issue since the latest bigger update of gcc:

In file included from /home/anton/.cache/yay/openswan/src/Openswan-3.0.0/lib/libopenswan/constants.c:32:
/home/anton/.cache/yay/openswan/src/Openswan-3.0.0/include/constants.h:52:13: error: ‘bool’ cannot be defined via ‘typedef’
   52 | typedef int bool;
      |             ^~~~
/home/anton/.cache/yay/openswan/src/Openswan-3.0.0/include/constants.h:52:13: note: ‘bool’ is a keyword with ‘-std=c23’ onwards
/home/anton/.cache/yay/openswan/src/Openswan-3.0.0/include/constants.h:52:1: warning: useless type name in empty declaration
   52 | typedef int bool;
      | ^~~~~~~
make[3]: *** [/home/anton/.cache/yay/openswan/src/Openswan-3.0.0/lib/libopenswan/Makefile:179: constants.o] Error 1
make[3]: Leaving directory '/home/anton/.cache/yay/openswan/src/Openswan-3.0.0/OBJ.linux.x86_64/lib/libopenswan'
make[2]: *** [/home/anton/.cache/yay/openswan/src/Openswan-3.0.0/lib/Makefile:37: programs] Error 1
make[2]: Leaving directory '/home/anton/.cache/yay/openswan/src/Openswan-3.0.0/OBJ.linux.x86_64/lib'
make[1]: *** [Makefile:10: programs] Error 1
make[1]: Leaving directory '/home/anton/.cache/yay/openswan/src/Openswan-3.0.0/OBJ.linux.x86_64'
make: *** [Makefile:186: programs] Error 2
==> ERROR: A failure occurred in build().
/usr/share/makepkg/util/message.sh: line 51: QUIET: unbound variable
/usr/bin/makepkg: line 133: logpipe: unbound variable
 -> error making: openswan-exit status 1
 -> Failed to install the following packages. Manual intervention is required:
openswan - exit status 1

lano1106 commented on 2021-02-26 22:21 (UTC)

Here is some heads up about v3.0.0. I had issue with it. I use openswan for a VPN connection as described here: https://wiki.archlinux.org/index.php/Openswan_L2TP/IPsec_VPN_client_setup

IPSec will only be established with the VPN gateway if I do use IPSec transport mode.

With v3.0.0, I have this error msg when doing: ipsec auto --up L2TP-PSK

003 "L2TP-PSK" #3: NAT-Traversal: Transport Mode not allowed due to security concerns -- using Tunnel mode. Rebuild Openswan with USE_NAT_TRAVERSAL_TRANSPORT_MODE=true in Makefile.inc to support transport mode.

I did try to recompile by following the warning message but it doesn't change anything.

I have tried to grep the source code to see where this define was used and it doesn't seem to be used anywhere except in the error text msg.

So IOW, as of right now, 3.0.0 appears broken for my application of it.

xexaxo commented on 2020-12-01 05:04 (UTC) (edited on 2020-12-21 03:27 (UTC) by xexaxo)

Please consider pulling my fix on the next update. Upstream has merged it, although it not in any release yet.

Edit: fix has been included in 2.6.52.3

xexaxo commented on 2020-09-28 16:43 (UTC)

You may want to include https://github.com/xelerance/Openswan/pull/447. Otherwise "self-proposal" errors may occur as seen in https://bbs.archlinux.org/viewtopic.php?id=253434.

buzz commented on 2020-07-09 17:59 (UTC)

Could you support aarch64?

I successfully compiled for this architecture by adding aarch64 to arch in PKGINFO.

Thank you

greenlean commented on 2020-05-21 09:40 (UTC) (edited on 2020-05-21 09:41 (UTC) by greenlean)

The package does not build on gcc 10-1. A workaround is to downgrade to gcc 9.2 and then build it.

$ yay -S downgrade # downgrade gcc gcc-libs

There are also issues with xmlto, is better to remove it: # pacman -R xmlto

lineage commented on 2020-01-30 19:24 (UTC) (edited on 2020-01-30 19:24 (UTC) by lineage)

One of the makefiles tries to remove a real system file during packaging. Non-root builds where a version is already installed barf. root builds would silently remove the file. This will fix it


--- programs/Makefile.program.orig      2019-06-14 20:35:45.000000000 +0100
+++ programs/Makefile.program   2020-01-30 18:54:31.226501106 +0000
@@ -112,7 +112,7 @@

 # note: remove any old vendor file installed previously
 doinstall:: $(PROGRAM) $(CONFFILES) $(EXTRA8MAN) $(EXTRA5MAN) $(EXTRA5PROC) $(LIBFILES) $(CONFDFILES)
-       @rm -f $(FINALLIBEXECDIR)/vendor
+       @rm -f $(LIBEXECDIR)/vendor
        @mkdir -p $(PROGRAMDIR) $(MANDIR8) $(MANDIR5) $(LIBDIR) $(CONFDIR) $(CONFDDIR) $(CONFDDIR)/$(CONFDSUBDIR) $(EXAMPLECONFDIR)
        @if [ -n "$(PROGRAM)" ]; then $(INSTALL) $(INSTBINFLAGS) $(PROGRAM) $(PROGRAMDIR); fi
        @$(foreach f, $(addsuffix .8, $(PROGRAM)), \

amdg commented on 2020-01-21 09:26 (UTC)

This package is missing the following build dependencies:

  • inetutils (hostname command used during build)
  • xmlto (used to generate man pages)
  • docbook-xsl (required to have xmlto working correctly)

severach commented on 2019-08-10 01:04 (UTC) (edited on 2019-08-10 01:06 (UTC) by severach)

The "normal" diff format isn't very good. It won't apply if everything isn't exact. The context and unified will apply. Unified are the easiest to read.

Subtracting 1 isn't enough. That may shut the compiler up but it will earn us a CVE. strncpy() does not guarantee a nul end of string. The referenced patch has a decent way to guarantee a nul but I like my way better because it also guarantees no random text can appear after the nul.

The real answer is to write a custom strncpy() that has all the behavior we want, guaranteed nul and all nul to end of buffer.

1 2 3 4 5 6 .. 9 Next › Last »