Re: Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
On Mon, Feb 1, 2010 at 6:10 PM, Paul Wise <email@example.com> wrote:
> On Mon, 2010-02-01 at 09:58 -0800, Luis R. Rodriguez wrote:
>> I can help with this only if no one else is up for it. I personally
>> however find building a key on the fly for each build pretty pointless
>> and would like to know if a package would be acceptable upstream on
>> Debian if OpenSSL is used to allow administrators to add their own
>> keys into the /etc/wireless-regdb/pubkeys/ dir for CRDA and from the
>> start only trust John's key.
> As part of upstream, you're probably the best person to do the packaging
> stuff for Debian.
OK, in that case here is my first shot at this.
Tim -- notice both packages have a Replaces: wireless-crda. If debian
upstreams both packages then I think it would be good to separate the
packages as I am recommending for integration on Debian and for Ubuntu
to also use the same debian packages as debian. I think this would
mean also having the new Ubuntu kernels depend on these new packages
instead of the old wireless-crda.
The package is very simple, I took what I could from Kel's work but
did leave in the signature check stuff, used openssl and also just
used cdbs. The wireless-regdb does not change *that* often so I do not
expect debian itself to need a custom regulatory database to be
automatically built and propagated so I left all the watch stuff out
and can do manual updates for now, I can commit to that for now. If
that is a requirement however, I am not that familiar with new package
policies and am unclear how to do that. I would prefer if we can get
something started and uploaded for now which at least meets the
requirements for integration into an eventual stable release, but
that's just me.
Please review and let me know what you think.
Also, a slightly related change is to change the kernel configuration
to disable CONFIG_WIRELESS_OLD_REGULATORY. Can someone take care of
that on the debian kernel side? We don't necessarily need to wait for
crda/wireless-regdb to do that.
> The idea was that by default there would be no Debian key installed
> because the text and binary databases would be unmodified. The build
> system would detect if Debian had patched the databases and if so
> generate a new key, sign the binary database with it and install the
> public key to the /etc/wireless-regdb/pubkeys/ dir. Debian might need to
> patch the database for the stable release.
> Thanks for all the information about how wireless card firmware and
> drivers interact with regulatory information.
>> > Hmmm, OK. I guess that makes sense. I imagine it will definitely be the
>> > source of some annoyance for users in the future though.
>> Tell me about it, but changing that would mean first getting
>> regulatory agencies to allow regulatory compliance to fall down to the
>> user when they customize a device's regulatory settings. As it stands
>> that is not the case so all we can do upstream for now is allow users
>> to enhance compliance, never allow more. There is also the complexity
>> of calibration involved in allowing new channels but that is a
>> separate topic as well.
> There is also the opportunity for user-based advocacy for change in the
> regulations. Whenever someone comes to the kernel wireless folks with a
> situation where they have been prevented from connecting to a wireless
> network because of restrictive wireless regulatory data, explain the
> issue and give them a form letter they can send to their local
> regulatory agency complaining about the situation and suggesting change.
> A list of relevant regulatory agency contact details would be useful
> here too I think.
Sure, we'll have to write something up for that on the wiki.
> Ideally the manufacturer should be obligated to give users hardware that
> can be compliant for any level of radio license and defaults to being
> compliant for the default radio license for the whole population. It
> would then be up to individual users to comply with the relevant radio
> license(s). Such a situation would then turn into a much bigger
> enforcement problem, I guess that is the main reason it doesn't work
> this way.
Right, I believe this ought to be the way things change for regulatory
compliance in the future too.