[FFE] Upgrade wpa_supplicant from 1.0 to 2.1

For anyone who wants to try this, I packaged wpa 2.0 in
  https://launchpad.net/~anders-kaseorg/+archive/ppa

I don’t have much data yet, but so far it seems to be working much better than 1.0.

Status changed to 'Confirmed' because the bug affects multiple users.

Fedora has a patch to make wpa_supplicant’s roaming less aggressive in the presence of wildly variable signal strengths:
  http://pkgs.fedoraproject.org/cgit/wpa_supplicant.git/tree/rh837402-less-aggressive-roaming.patch?h=f18
I added it to my PPA package.

AFAIK version 1.1+ will also bring WIFI Direct, which is now supported by any Android 4.0 device.

So it's a nice feature to have, and I guess a lot of people will want this

I backported the load of PMKSA patches to wpa 1.0 or so before for another project, it seems to me like it would be something that could be applied as SRU to the package we have currently.

It's quite late though to be changing wpa now for an upgrade, the right thing to do would be to identify the exact issues that are currently see (Anders, please file a bug specifically for the issues you're seeing on the MIT network, with logs and testing with the patches, if possible) so that these issues can be handled via patches and the SRU process.

As soon as Debian has 1.1 or 2.0 or any other version of wpa available, we'll sync it into Ubuntu, once the next dev release opens. For now, I'm marking this as Wishlist/Triaged.

Hi Anders Kaseorg, seems to be you tried to update wpa without prior checking out the debian (unreleased) changes
http://anonscm.debian.org/viewvc/pkg-wpa/wpa/trunk/

many of the ubuntu deltas have been already accepted into debian, so I tried to merge debian/your/my work together in a single package

It will be available in debian mentors [1], feel free to "dget -x " of the dsc file and upload this version into your ppa!

Let me know if I packaged it correctly, I'll try to get a sponsor for debian soon.
(sorry, seems to be debian wants to switch to xz source file, I hope this isn't a problem for you)

[1] https://mentors.debian.net/wpa

I actually tried to find the mentors.debian.net package, but failed (https://mentors.debian.net/wpa 404s, https://mentors.debian.net/package/wpa redirects somewhere useless). Thanks for the more direct pointer.

I’m not officially an Ubuntu developer, but AFAIK there’s no problem with xz sources in current Ubuntu releases.

Sorry, available here [1]
(I had a problem in uploading to mentors, bad connection)

[1] https://code.launchpad.net/~costamagnagianfranco/+archive/locutusofborg-ppa/+packages

The problem is not in ubuntu itself, neither in launchpad, just you already uploaded the same version with a different binary content, I don't know if launchpad builders will complain about the content changed on the source binary, in this case just grab the debian directory from my ppa!

No, there’s no problem here. Launchpad will prevent you from uploading different orig tarballs with the _same filename_ to the _same PPA_, but the .xz tarball has a different filename, and you uploaded it to a different PPA.

However, you should be more careful about the version number of packages you upload to a PPA. 2.0-1.1 is newer than the first 2.0 version that might be uploaded to either Debian or Ubuntu proper. You should use versions like
  2.0-0ppa1 if 2.0 is in neither Debian nor Ubuntu yet,
  2.0-0ubuntu3ppa1 if 2.0-0ubuntu3 is in Ubuntu,
  2.0-3ppa1 if 2.0-3 is in Debian.
https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage

> to the _same PPA_

yeah I know, I was wondering for you, you already have the same version with different orig in your ppa, anyway thanks for the explanation

http://mentors.debian.net/package/wpa

 2.0-1.1 will be the version accepted in debian if my upload goes successfully accepted.
2.0-1 is the base revision (the -0 seems to be not used anymore), and .1 stands for NMU (Non-maintainer upload)

so e.g. 2.0-1~saucy1 for me is perfectly legal
(anyway I uploaded it into my ppa just for letting you grab the source package, I don't know if I'll leave it)

No, if a new upstream version is packaged as an NMU in Debian (so there’s no -1 yet), the Debian revision is -0.1:
  http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-changelog
Also, if Ubuntu uploads it before Debian, the Ubuntu revision is -0ubuntu1.

LocutusOfBorg: It looks like you chose to change CONFIG_TLS from openssl to gnutls. I’m concerned that GnuTLS support in wpa_supplicant is not fully baked security-wise, given these comments:

src/crypto/tls_gnutls.c: /* TODO: gnutls_certificate_set_verify_flags(xcred, flags);
src/crypto/tls_gnutls.c- * to force peer validation(?) */
src/crypto/tls_gnutls.c: /* TODO: validate subject_match and altsubject_match */

That change can close
(Closes: #667706, #561081, #574714, #668612, LP: #429370)

Anyway, I uploaded on mentors and my ppa the correct version (thanks for pointing to me the right docs!)

what do you suggest before asking for a sponsorship? gnutls or openssl?

Maybe the 4 bugs are solved with the other changes, not required to switch to gnutls

Yeah, I would suggest sticking with OpenSSL for now. Fewer changes at a time is good. Then you can work with upstream to get input on those 4 bugs—actually they’re all the same bug, since they’ve been merged together—and if gnutls is really the right solution, work with upstream to get the code up to production quality.

(I haven’t looked at the bug in detail, but what it looks like on the surface is that OpenSSL has better security features enabled by default, such as BEAST attack mitigation, that may interfere with old networks with buggy SSL implementations. If that’s what’s going on, the right answer is to get those networks fixed, but it should also be possible to optionally disable those better security features in OpenSSL.)

What's the state of this? The wpa supplicant version currently available is REALLY old!

2.1 is available since two weeks. It would really make sense to have trusty ship with that version.
http://lists.shmoo.com/pipermail/hostap/2014-February/029440.html

Filing this as a Feature Freeze Exception now, 1.0 is very old (two years old), now considered end of life, and 2.0 has been released a year ago.

I have built 2.0 in my PPA and provided it for testing with no issues reported so far, and have been running it for over a month.

I will prepare an updated package for 2.1 and provide it for more spot checking.

In the interest of continued upstream support for the support lifetime of trusty, I think we should upgrade to 2.1.

I will attach the usual changelog diffs and build logs specific to 2.1 shortly.

Manual esting that was done for 2.0:
 - scanning, connecting, etc. (via NM)
 - WPA2 personal
 - WPA2 enterprise (PEAP, with certificates and password)

There are also autopkgtests run via network-manager which exercise wpasupplicant features, which should trigger for every new upload of wpa.

Back to NEW, will transition to Triaged when the FFE is acked by the release team.

Just a question, isn't better to upload in debian and then sync rather than uploading on ubuntu only?

I think that's just a matter of timing, given that we are already past feature freeze on an LTS. There is certainly interest in getting this into Debian as well.

Mathieu, can you give us an high level changelog for the new wpa? I'm mostly interested in potentially user visible features and anything that may require config changes (if any).

Overall, I do agree that we should get 2.1 for 14.04, it's just unfortunate that this missed the freeze, so the sooner we get this in the better (so long as we're fairly sure it's regression free).

High-level changelog for changes from 1.0 to 2.1

The same for hostapd (included in the wpa source)

Debdiff between the version currently in Ubuntu and wpa 2.1-0ubuntu1.

Build logs

That's a lot more changes than I like to see after Feature Freeze, however I believe that cherry-picking every single fixes and maintaining that for the next 5 years would lead to more problems than just getting the new upstream, so go ahead...

FFe granted.

If you wouldn’t mind, please include this post-2.1 regression fix (so we don’t break several deployed WPA-Enterprise networks, such as MIT SECURE):

http://hostap.epitest.fi/cgit/hostap/commit/?id=b62d5b5450101676a0c05691b4bcd94e11426397

This bug was fixed in the package wpa - 2.1-0ubuntu1

---------------
wpa (2.1-0ubuntu1) trusty; urgency=medium

  * New upstream release (LP: #1099755)
  * debian/get-orig-source: update for new git repository for the current
    hostap/wpasupplicant versions.
  * Dropped patches due to being applied upstream and included in the current
    source tarball:
    - debian/patches/11_wpa_gui_ftbfs_gcc_4_7.patch
    - debian/patches/13_human_readable_signal.patch
    - debian/patches/git_deinit_p2p_context_on_mgmt_remove_ff1f9c8.patch
    - debian/patches/libnl3-includes.patch
  * debian/patches/git_accept_client_cert_from_server.patch: revert the commit:
    "OpenSSL: Do not accept SSL Client certificate for server", which breaks
    many AAA servers that include both client and server EKUs. Cherry-picked
    from hostap git commit b62d5b5.
 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 04 Mar 2014 16:13:24 -0500

After upgrading to 2.1, I've got this problem: https://bugs.launchpad.net/wpasupplicant/+bug/1291331