Bug#683683: unblock: openswan/1:2.6.38-1
Hi Harald and Jonathan, I agree with going for the backports option so as not to delay the freeze period any more than necessary. However, the typical issue with openswan will remain in this case: security updates will be more difficult to backport to the version currently in wheezy (just judging from experience). Although I would prefer the new version to enter testing, I understand the caution against such a request. best regards, Rene On 01.01.2013 19:10, Harald Jenny wrote: Hi Harald, Hi Jonathan Harald Jenny wrote: I have retitled the bug request to unblock: openswan/1:2.6.38-1 The version is now in unstable and awaits your (hopefully positive) decision. debdiff attached for reference. diffstat: 598 files changed, 11061 insertions(+), 5908 deletions(-) Is there some subset of these changes that can bring about the same interoperability improvement? Any words to calm fears about the chance of regression among these changes? Well the unblock request was made some months ago at the beginning of the freeze where a new upstream version wouldn't have been such a great issue I presume but now at this stage of the freeze I consider it not appropriate anymore to do such a migration. For the interop fixes maybe they could be backported but openswan upstream is dead and the project already got forked so we won't realy get help and testing for this task. I am not an expert in this area at all, but I fear that without further information the most likely release team reply is negative. I guess so too therefore I'm currently thinking about chancelling the unblock request and instead prepare a backport for wheezy-backports ASAP - Rene what is your opinion on this matter? Hope that helps, Jonathan Yes thanks I will wait for Rene's answer and then presumably close this request, thanks Kind regards Harald -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e71182.6070...@debian.org
Bug#683683: unblock: openswan/1:2.6.38-1~experimental+1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package openswan because it fixes interoperability with the increasingly important mobile devices (Android and iOS) under NAT-Traversal conditions. unblock openswan/1:2.6.38-1~experimental+1 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/501accd6.4040...@debian.org
openswan freeze exception
Dear release team, Unfortunately, we (Harald Jenny, the real maintainer of openswan for the past 6 months or so, and me, the one who is only doing uploads) missed the freeze deadline due to various issues. However, we feel that the version of openswan that is now in experimental (and which we plan to upload to unstable as soon as you agree to it) is indeed needed in Wheezy, because it fixes a few important bugs concerning compatibility with mobile clients such as iOS and Android devices particularly in combination with NAT traversal (which most mobile devices will have to go through). Unfortunately, fixing these bugs requires a new upstream version with a few cherry-picked patches. Internal testing indicates that it is stable and does not introduce any regressions. Would you consider openswan for a freeze exception at this time? best regards, Rene -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ff8c6fc.4040...@debian.org
Re: Fwd: Bug#616482: strongswan-ikev1: virtual ips not released if xauth name does not match id
Am 2011-05-15 13:30, schrieb Philipp Kern: On Fri, Apr 22, 2011 at 12:00:41AM +1000, Julien Cristau wrote: On Sat, Apr 16, 2011 at 22:19:43 +0200, René Mayrhofer wrote: Would you prefer that I upload a new package with the fix to debian/rules network-manager handling with a new version or just again with the same one? I think we'd prefer to just have a fix for #616482. This I use debian/source/format v3 but in reality I don't is a tad annoying. You should mark #616482 as fixed in unstable, too. So NACK on the configure stuff. ACK for the fix itself (a sane diff to the previous version in stable appreciated) Attached is only the patch to be applied to fix #616482. Additionally, debian/rules needs this fix: diff --git a/debian/rules b/debian/rules index 65cade0..b88b838 100755 --- a/debian/rules +++ b/debian/rules @@ -53,7 +53,7 @@ endif # to do backports where the network-manager libs can not be installed, and # thus to just ignore build-deps). ifeq ($(shell test -d /usr/include/libnm-glib/ echo yes),yes) - CONFIGUREARS += --enable-nm + CONFIGUREARGS += --enable-nm endif build: build-stamp and the NAT-T stuff could be done with a very good reason. (Don't do it, it's insecure vs. hey, it's now common to do insecure stuff, so let's allow it isn't exactly that convincing, yet.) Well, unfortunately that's the practical use-case right now. Without--enable-nat-transport, no smart phone will be able to connect when it's behind a NAT, because most of them (including iPhone and Android) use L2TP-over-IPsec by default and therefore rely on transport connections. We know that there are some security weaknesses of NAT-T for transport connections, which are (hopefully) alleviated by the L2TP server (which should be the only allowed traffic through that IPsec transport connection). I would therefore prefer to have it enabled at this time, because you otherwise prevent a lot of potential clients from connection to a strongswan IPsec gateway. And yes, most commercial IPsec gateways (e.g. included in Linux-based firewalls) enable this right now. best regards, Rene signature.asc Description: OpenPGP digital signature
Re: Fwd: Bug#616482: strongswan-ikev1: virtual ips not released if xauth name does not match id
Am Freitag 15 April 2011, um 19:33:05 schrieb Adam D. Barratt: On Wed, 2011-04-06 at 21:46 +0200, René Mayrhofer wrote: I have now integrated the cherry-picked upstream patch into my strongswan-sqeeze branch at the alioth git repository (ssh://alioth.debian.org/git/pkg-swan/strongswan.git). As mentioned in the bug report, it applies cleanly and is an isolated fix for a bug in version 4.4.1 that impacts some clients. It looks like we managed to miss this when it was originally sent; apologies for that. However, a lack of response should only be treated as that, not as an implicit ack for an upload. I will remember that for future uploads. Why have the configure options in debian/rules been modified, with no mention of this in the changelog? So far as I can see, --enable-pkcs11, --enable-eap-tls, --enable-eap-ttls and --enable-led have been added. The addition of --enable-nat-transport /is/ mentioned in the changelog, but was not mentioned in your mail to -release. Sorry about that, I only mentioned the last change that actually triggered the desire to get it into proposed-updates for squeeze. The other changes were made in my squeeze branch of strongswan that I use in production for the Gibraltar firewall. Enabling the additional modules was required in some cases but should not lead to any regressions, as these modules need to be enabled explicitly in the config file to be used. With default config, that means no changes to the previous version in squeeze. There are also several other changes related to the removal and re-enabling under certain circumstances of the Network Manager support. The associated comments indicate that this change was intended to ease backports, so I'm not sure why this is being included in a stable update; again, these changes are not mentioned in the changelog. Furthermore, the n-m changes are actually buggy: + CONFIGUREARS += --enable-nm That should presumably be CONFIGUREAR*G*S. Thanks for spotting that, I have fixed it in my git branch. The change was indeed made for the same in-production packages we use, as the older version of Gibraltar firewall is based on Lenny and we backport important packages such as strongswan. The current version has been tested by us on many fireewalls and by the original bug reporter without any regressions being found. Would you prefer that I upload a new package with the fix to debian/rules network-manager handling with a new version or just again with the same one? best regards, Rene signature.asc Description: This is a digitally signed message part.
Fwd: Bug#616482: strongswan-ikev1: virtual ips not released if xauth name does not match id
Dear stable release team, I have now integrated the cherry-picked upstream patch into my strongswan-sqeeze branch at the alioth git repository (ssh://alioth.debian.org/git/pkg-swan/strongswan.git). As mentioned in the bug report, it applies cleanly and is an isolated fix for a bug in version 4.4.1 that impacts some clients. We will integrate this patched version into our Gibraltar firewall release and will therefore test this package update for regressions within the next few days. I would then prepare an upload to stable to make it into squeeze proposed updates. Is this ok for you? If you can't directly look at the strongswan-squeeze git branch, I could send you the most current 4.4.1-7 package diff. best regards, Rene ---BeginMessage--- Package: strongswan-ikev1 Version: 4.4.1-5.1 Severity: normal Tags: patch upstream In Strongswan version 4.4.1 as shipped in stable there is a known bug which prevents a virtual ip assigned via mode config to be released if the XAUTH name send from the peer does not match the peers id. Clients which offer no control over which peer id is send or extract it from the certificates subject will not be able to aquire a virtual ip after their first disconnect. One particular example of this peer behaviour are iphones. For theses clients the current strongswan-ikev1 package is not usable with the xauthrsasig method. Upstream has a patch for this at http://git.strongswan.org/?p=strongswan.git;h=2b3124c76d3897bccb4aa616fca1f7393f1b284e The patch applies cleanly to the debian source package and solves the problem described. -- System Information: Debian Release: 6.0 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages strongswan-ikev1 depends on: ii bind9-host [host]1:9.7.2.dfsg.P3-1.1 Version of 'host' bundled with BIN ii bsdmainutils 8.0.13 collection of more utilities from ii debconf [debconf-2.0 1.5.36.1Debian configuration management sy ii debianutils 3.4 Miscellaneous utilities specific t ii iproute 20100519-3 networking and traffic control too ii ipsec-tools 1:0.7.3-12 IPsec tools for Linux ii libc62.11.2-10 Embedded GNU C Library: Shared lib ii libcap2 1:2.19-3support for getting/setting POSIX. ii libstrongswan4.4.1-5.1 strongSwan utility and crypto libr ii strongswan-starter 4.4.1-5.1 strongSwan daemon starter and conf strongswan-ikev1 recommends no packages. Versions of packages strongswan-ikev1 suggests: pn curl none (no description available) -- no debconf information ---End Message--- signature.asc Description: This is a digitally signed message part.
Re: strongswan update to 4.4.x
On Thursday 26 August 2010 22:18:23 Mehdi Dogguy wrote: On 08/22/2010 12:33 AM, René Mayrhofer wrote: Dear release team, The 4.4.x upstream series of strongswan fixes many issues of the 4.3.x series which is currently in Squeeze. Unfortunately, due to real life constraints on my part coupled with upstream packaging changes that required a few tries to get right on the Debian package side, I didn't manage to update it in time for the freeze. Trying to see how it looks like, I ended up with a big diff. 489 files changed, 27220 insertions(+), 11439 deletions(-) Is there any sane way to review this? Has any decision been reached towards updating strongswan for Squeeze? I am strongly pushing for its inclusion, as it really seems more stable on production systems in our in-house tests here. best regards, Rene signature.asc Description: This is a digitally signed message part.
Re: strongswan update to 4.4.x
On Thursday 26 August 2010 22:18:23 Mehdi Dogguy wrote: Trying to see how it looks like, I ended up with a big diff. 489 files changed, 27220 insertions(+), 11439 deletions(-) Is there any sane way to review this? Maybe the best way would be to contact upstream. In my experience, Martin Willi and Andreas Steffen are very willing to actively interact with us. They might be able to provide a detailed info on what has changed from 4.3.x to 4.4.1 and which impact this might have on stability. In general, it certainly seems to me that 4.4.x is more stable in practice than 4.3.x. best regards, Rene signature.asc Description: This is a digitally signed message part.
strongswan update to 4.4.x
Dear release team, The 4.4.x upstream series of strongswan fixes many issues of the 4.3.x series which is currently in Squeeze. Unfortunately, due to real life constraints on my part coupled with upstream packaging changes that required a few tries to get right on the Debian package side, I didn't manage to update it in time for the freeze. However, many current strongswan users ask for a 4.4.x version in Squeeze, and I agree that this is much preferrable to the current version in testing. See e.g.: #506320: strongswan: include directives error and ikev2 #569550: strongswan: Please include attr plugin #593768: strongswan: 4.4.1 unavailable in testing notwhistanding a freeze- exception request Additional upstream changes in 4.4.0 include: * The ipsec pki utility, easing PKI/X.509 handling. * farp and dhcp plugins for better road-warrior integration into internal network services. Please add an exception for strongswan to allow 4.4.x into testing/Squeeze, as it greatly improves usability over the 4.3.x series. PS: An upload (hopefully) fixing the FTBFS (which never happened on my systems) is pending. I intend to upload on Monday after verifying another fix. best regards, Rene signature.asc Description: This is a digitally signed message part.
