Bug#536502: Debian status of crda & wireless-regdb?
Hi Paul,
On Monday 17 August 2009 14:31:41 Paul Wise wrote:
> On Sun, 2009-08-16 at 21:34 +1000, Kel Modderman wrote:
>
> > My take on packaging crda/wireless-regdb can be seen/tested at:
> >
> > crda:
> > Vcs-Svn: svn://svn.debian.org/pkg-wpa/crda/trunk
> > Vcs-Browser: http://svn.debian.org/wsvn/pkg-wpa/crda/trunk/
> >
> > wireless-regdb:
> > Vcs-Svn: svn://svn.debian.org/pkg-wpa/wireless-regdb/trunk
> > Vcs-Browser: http://svn.debian.org/wsvn/pkg-wpa/wireless-regdb/trunk/
> >
> > Comments from my point of view:
> > * the legal consequences of disabling crypto verification of regulatory.bin
> > concern me because I simply do not know if there could be any in the future.
>
> Ah, why was crypto verification disabled? In any case the software is
> FLOSS and anyone could patch it to set arbitrary regulatory info so a
> bit of crypto verification isn't more than a slight bump for someone who
> wants to violate spectrum regulations.
It was disabled to build it sanely in Debian. Work to do this without patching
can be done progressively, I think, by developing and sharing generic patches
to build system with upstream.
>
> > * other consequences of disabling crypto verification are keeping Debian
> > specific patches in sync with upstream. They are pretty simple though.
>
> Upstream seemed fairly reasonable to me so I imagine they would accept
> anything implemented generically enough.
Ack.
>
> > * your previous comments contained something about developing a package for
> > backporting to a theoretical lenny + 1/2 - I have no interest in targetting
> > a package for anything other than current testing/sid and using all good
> > features currently available there. If it is easy enough to make it
> > backportable patches would be welcome.
>
> Fair enough. Given that the Debian release managers want to freeze for
> squeeze in December to sync with Ubuntu, lenny and a half is unlikely to
> happen or be needed.
>
> > * enabled use of dpkg trigger to synchronise the country name -> country code
> > matrix parsed from tzdata's zone.tab file. The result is stored in
> > /etc/default/crda in a section clearly labelled as automatically managed by
> > maintainer scripts. All other modification to the conffile done by admin are
> > preserved.
>
> That bit looks good to me, I haven't tested it though.
>
> > Am not fully committed to maintaining these packages, would file ITP's
> > if I was. Need to get (active) co-maintainers but haven't made a huge effort
> > to do that yet.
>
> Fair enough.
>
> > Would you be interested in being a co-maintainer or making package uploads
> > with me?
>
> The most I could commit to would be sponsorship and review of the
> packaging and upstream's mechanisms. At first glance the current
> packaging looks generally good, although I think a fair bit of stuff
> could be pushed upstream, even the patches marked Debian-specific.
Okay. I'm afraid I will be unable to work on this until November at the
earliest due to relocating self internationally via a whole bunch of nice
locations. It'd be nice if someone picks up my work, or at least finds
some of it useful as they forge out their own package(s) in the next month
or 3.
>
> Is upstream still embedding the RSA public keys in the crda binary?
Yes.
>
> PS: any idea if GNOME/KDE will be using GeoClue or similar mechanisms to
> detect the appropriate regulatory domain and set it automatically?
IIRC, Luis the crda upstream expressed his desire for this to happen somewhen
but I am not personally aware of any work toward this.
Thanks, Kel.
Reply to: