On Thu, Jan 28, 2010 at 6:57 PM, Paul Wise <p...@debian.org> wrote: > [Please keep me in CC for this thread] > > There is a technical change coming in Debian that may mean one key for > the pkg-wpa folks will be more problematic; it is planned that > maintainer-built .debs are to be thrown away on upload (but still > required) and all packages rebuilt on the buildds. There will probably > be the possibility to have exceptions though, so this may turn out to be > a non-issue or less of an issue. > > Also, IIRC I wasn't fully happy with the way the signature stuff worked. > My main issue was that the trusted RSA public keys are/were embedded > into the crda binary at build time. I would have much preferred that > they be split out into a set of directories. Something > like /etc/crda/keys/ could be the default. This allows packages to drop > new keys in and for sysadmins to also do that as needed, as well as for > sysadmins to disable keys that have been compromised or similar. With > the dir list and the upcoming buildd change, Debian could use something > like Fedora's option; > > * wireless-regdb could check at build time if the source database > has been modified and a new binary database been rebuilt > * If so > * generate a new temporary key at build time > * sign the new binary database with the temporary > key > * install the temporary public key > to /etc/crda/keys/ > * throw away the temporary private key > * If not > * install the (unmodified) pre-built binary > database > > I imagine the OpenSSL stuff in crda 1.1.1 would enable this kind of > option.
Exactly, this is already taken care of upstream with OpenSSL. The default directory is /etc/wireless-regdb/pubkeys/ > In addition, crda should have a directory for the sysadmin to > drop in a replacement binary database if for example they wanted to > replace their distro's binary database with a newer version from John > Linville. Patches for this are welcomed upstream on CRDA. Is this a requirement for Debian to package CRDA? > Since the distros should install John's RSA key, new versions > of the pre-built binary database would be trusted. If the sysadmin > wanted to build their own binary database they would install the > temporary key generated above as well as their new database. Sure. > What is the point of having the CFG80211_INTERNAL_REGDB option? That > sounds like a silly thing to do since there is crda and wireless-regdb. Some embedded solutions might make use of this but even today's embedded solutions like openwrt do use CRDA through userspace. The CFG80211_INTERNAL_REGDB motivational effort actually came out of the incentive to support new 2.6.32 drivers backported on older kernels which do not have generic netlink supported. If you want to backport proper CRDA support to older kernels and you will deal with proper kernel upgrades when regulatory updates are made this is a nice option. It also is a good way to finally remove the old crappy regulatory stuff we had which had only 3 static regulatory domains built in, instead now you can have properly updated static regulatory domains based on the same wireles-regdb db.txt. > Since 2.6.33 isn't yet released, I assume there is time to change the > behaviour of CFG80211_INTERNAL_REGDB (or remove it). Does > CFG80211_INTERNAL_REGDB mean that crda will be consulted first and if it > cannot be contacted, then the internal copy will be used? You mentioned > the embedded world, I suppose that is the target for it? I know of no users yet of this, including on embedded systems. The way it works is it will first use the local database first and then call CRDA. If CRDA is present then it will update the regulatory information based on CRDA. > Any idea what proportion of wireless card firmware will respect what > Linux and crda tell it? All wireless drivers respect this, regardless of if you have firmware or not. > I guess users of old wireless cards with > abandoned or hard-coded firmware will not benefit from crda & > wireless-regdb. Actually all wireless drivers do benefit from it. Note that all new wireless drivers upstream are expected to be either cfg80211 based or mac80211 based, that's it. The new regulatory infrastructure is part of cfg80211 and since all mac80211 drivers are cfg80211 drivers that means *every* wireless driver benefits from this and uses it. The exemption then just becomes the old wireless-extensions only based drivers. Some effort by some developers has been made to start porting some of those drivers to cfg80211, the list of remaining drivers to port can be found here: http://wireless.kernel.org/en/developers/todo-list/cfg80211-conversion The other exemption is staging drivers but those are all TAINT_CRAP anyway so who the fuck cares about them. > I speak here as a user of the ar6000 on the OpenMoko FreeRunner ar6k is not upstream and uses wext only so it does not use cfg80211. A respective upstream driver would use cfg80211. > and a friend of people with ipw2x00-based cards on laptops. Old ipw falls under the not-converted stage but I thought there were patches for converting these to cfg80211 already. I forget. I should note though that some firmware already have their regulatory stuff built-in to the firmware, just as some cards are configured on their EEPROM to use only one country. In those cases the regulatory infrastructure just helps regulatory compliance further, it would never allow more channels, for instance. > I'm using an iwl3945-based card, do you know if Intel plan to implement > support for this stuff in their firmware? iwl3945 is a mac80211 driver so it also uses cfg80211 and therefore the same regulatory framework. > I thank you very much for working on this stuff. No problem, please let me know if you have any other questions or if there is anything else I can do to try to help. Luis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
