The current strongSwan ebuild misses several things: (1) It does not (optionally) enable openssl/gcrypt support. This leaves out several encryption/signature (e.g. ECDSA, ...) algorithms. If a user now tries to use the new PKI management of strongSwan together with one of those algorithms, it will fail with a rather cryptic message, leaving the user in the dark. (2) strongSwan supports sqlite/mysql for logging and more. Yet there is no way to enable it for the user. (3) strongSwan is quite modular, leaving it up to the user what is desired and what is not. Again, the ebuild does not expose this. The attached ebuild fixes (1) + (2), updates the description to be more precise and gives the user a few more options to enable/disable (3). What still needs to be done: *) enable networkmanager plugin *) expose more configuration options to the user where reasonable *) check kernel configuration for required options like ipsec-tools ebuild Nevertheless this should go straight into ~arch IMHO as it is an improvement and should by no means introduce any new bugs/defects. Reproducible: Always
Created attachment 222329 [details] updated strongswan-4.3.6 ebuild
FYI: I'll be posting a new revision soonish. With some more "fundamental" changes.
Created attachment 222877 [details] strongswan-4.3.6-r1.ebuild Changelog: - removed static use flag The flag was misleading. It disabled shared libs and only enabled the static ones. So one ended up w/ binaries that had all strongswan related parts statically linked in and were still dynamically linked against several system libs. So not quite what one would expect. True static binaries are not supported out of the box. - removed xml use flag Was misleading. Nothing visible or beneficial changed for the user. It actually enabled the new (and still WIP) SMP Control Interface which is XML based. - disabled static libs strongswan installs no headers or alike, so they are not really useful. - filtered .la files Unnecessary. No static libs, just internal usage etc... - tightened directory permissions Changed those from 0755 to 0750. There is sensitive data in those dirs that not every user on a server needs to read. If a user upgrades from an older version, this is handled and the user gets informed that the directory permissions have been adjusted accordingly. - overhauled and added warn/log messages - changed behaviour of the caps use flag and introcuded non-root flag Up until now the ebuild forced non-root priviledges onto strongswan if one had the caps use flag set. This is IMHO suboptimal. Non-root operation and capability dropping are two seperate security measures that one can combine or can use seperately. The user should have the choice. If for example root operation was desired, the user would have had to remove the caps flag along with the capability dropping. Since strongswan has a few limitations without superuser priviledges, this might not be all too uncommon. So caps does now only enabled/disable libcap support and I introduced non-root for reduced priviledges. - changed use flag defaults Made caps and non-root enabled by default which is the most secure. The help msg will inform the user appropriately about the limitations, so a conscious choice can be made. This ebuild has been tested on my local machine as well as on my server. I have it running on both in non-root operation just fine.
Created attachment 222881 [details] strongswan-4.3.6-r1 (fixed identation) somehow the identation got mixed up... fixed now.
+ 16 Mar 2010; Patrick Lauer <patrick@gentoo.org> + +strongswan-4.3.6-r1.ebuild, metadata.xml: + Improved ebuild, thanks to Matthias Dahl. Proxymaintaining with Matthias + now. Fixes #308101
