Package Details: openswan 3.0.0-1

Git Clone URL: (read-only, click to copy)
Package Base: openswan
Description: Open Source implementation of IPsec for Linux
Upstream URL:
Licenses: GPL, custom
Conflicts: ipsec-tools, strongswan
Submitter: Allan
Maintainer: severach
Last Packager: severach
Votes: 142
Popularity: 0.000000
First Submitted: 2009-11-07 14:39 (UTC)
Last Updated: 2022-01-30 19:36 (UTC)

Dependencies (6)

Required by (2)

Sources (2)

Latest Comments

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

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:

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 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

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

You may want to include Otherwise "self-proposal" errors may occur as seen in

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
-       @rm -f $(FINALLIBEXECDIR)/vendor
+       @rm -f $(LIBEXECDIR)/vendor
        @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.

mickybart commented on 2019-08-09 19:26 (UTC)


I have the same issue when I copy/paste it from my comment.

Here is base64 version to avoid that as I don't know how to share it in a proper way.

echo "MjMzYzIzMwo8IAkJCXN0cm5jcHkoaWZyLmlmcl9uYW1lLCBvcHRhcmcsIHNpemVvZihpZnIuaWZyX25hbWUpKTsKLS0tCj4gCQkJc3RybmNweShpZnIuaWZyX25hbWUsIG9wdGFyZywgc2l6ZW9mKGlmci5pZnJfbmFtZSktMSk7CjIzNmMyMzYKPCAJCQlzdHJuY3B5KHNoYy5jZl9uYW1lLCBvcHRhcmcsIHNpemVvZihzaGMuY2ZfbmFtZSkpOwotLS0KPiAJCQlzdHJuY3B5KHNoYy5jZl9uYW1lLCBvcHRhcmcsIHNpemVvZihzaGMuY2ZfbmFtZSktMSk7Cg==" | base64 -d > gcc9-fix.patch

the sha512sum is d4b5c8418cb623fc720d9e401cbbaf1668c172af8b5c658f95efadcce165840fd35c3f4dbb62925de73c1c3e212093e2cb427424b0db4e92ff96eb1c83cd84c4

stramaz commented on 2019-08-09 14:35 (UTC) (edited on 2019-08-09 14:39 (UTC) by stramaz)

Unfortunately the patch of @mickybart doesn't work for me...:

==> Starting prepare()...
patching file programs/tncfg/tncfg.c
Hunk #1 FAILED at 233.
Hunk #2 FAILED at 236.
2 out of 2 hunks FAILED -- saving rejects to file programs/tncfg/tncfg.c.rej
==> ERROR: A failure occurred in prepare().
:: Unable to build openswan - makepkg exited with code: 4