hostapd: 2.9 -> 2.10; wpa_supplicant: 2.9 -> 2.10

[mweinelt]

Motivation for this change

https://w1.fi/security/2022-1/sae-eap-pwd-side-channel-attack-update-2.txt
https://w1.fi/cgit/hostap/plain/hostapd/ChangeLog
https://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[picnoir]

Is there a particular reason for this URL change? The pointed content seems identical.

[picnoir]

I guess explicitly pointing to a specific commit pins a bit further the content, sounds good to me.

[mweinelt]

Yeah, it was scratching an itch.

[picnoir]

Manually tested this on a couple of deployments.

LGTM

[SuperSandro2000]

Nit: Since we are not using the github link we could have also used fetchpatch.

[ncfavier]

Am I the only one for whom this completely broke wpa_gui? (The program starts but the window is never drawn)

I bisected it to upstream commit eadfeb0e93748eb396ae62012b92d21a7f533646 (you can clone the repo from http://w1.fi/hostap.git), looking into what's wrong now.

[vcunat]

For me it shows the window well, but my machine does not have wpa_supplicant or WiFi.

[ncfavier]

Ok so the problem is that my list of networks (wpa_cli list_networks) looks like

0   mutable0
1   mutable1
2   mutable2
...
0   immutable0
1   immutable1

(I am using networking.wireless.allowAuxiliaryImperativeNetworks)

and the logic in that commit assumes that the IDs are strictly increasing, otherwise it might get stuck in an infinite loop.

The fact that the immutable network IDs start again from 0 is probably a bug in our 0001-Implement-read-only-mode-for-ssids.patch, cc @Ma27 EDIT: never mind, it's because -c and -I both result in a call to wpa_config_read, which starts numbering at 0. Definitely an upstream bug.

Fixing this could be as simple as declaring the id and cred_id variables in wpa_config_read as static.

[Ma27]

Definitely an upstream bug.

Well, we (to be precise, I) messed around in their code, so not sure if that still counts as upstream bug :)

I'll take a look.

[ncfavier]

I mean that it would still happen without your patch.

[ncfavier]

Using the patch suggested above solves the issue:

--- a/wpa_supplicant/config_file.c
+++ b/wpa_supplicant/config_file.c
@@ -297,8 +297,8 @@ struct wpa_config * wpa_config_read(const char *name, struct wpa_config *cfgp)
 	struct wpa_ssid *ssid, *tail, *head;
 	struct wpa_cred *cred, *cred_tail, *cred_head;
 	struct wpa_config *config;
-	int id = 0;
-	int cred_id = 0;
+	static int id = 0;
+	static int cred_id = 0;

 	if (name == NULL)
 		return NULL;

[Ma27]

Seems reasonable to me. Do you want to file a PR? %)

[ncfavier]

Yes, I'll send the patch to their mailing list.

[Ma27]

I'd say it's OK to file a PR here as well :)

[ncfavier]

Oh, yes, will do that as well.

[ncfavier]

Opened #158505 and sent the patch upstream