[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [renamed] Debian crda?

On Thu, Mar 26, 2009 at 1:19 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:

>> Brainwave: no need to add a second public key to CRDA itself, the
>> wireless-regdb could install the public key corresponding to the
>> private key it was built with.
> Can you elaborate on what you mean? Do you mean for wireless-regdb to
> put the actual pubkey into the users' system somewhere? Otherwise not
> sure what you mean.

The crda package would contain the default upstream public key.

The wireless-regdb would ship the Debian maintainer's pubkey as
debian/pubkeys/debian.pem in the source package and
/lib/crda/pubkeys/debian.pub.pem (or similar) in the binary package.

Ubuntu would add their pubkey in a similar way.

When wireless-regdb is built, it would:

check the sha1sum/sha256sum of db.txt (alternatively upstream could
add a detached signature if possible to the tarball/git repo)

if the db.txt is identical to the upstream one (or signed by
upstream), ship the upstream regulatory.bin file

if the db.txt has been modified:

if no private key is available, generate one automatically

rebuild the regulatory.bin file using the private key

create the corresponding public key and install it in the package as
/lib/crda/pubkeys/custom.pub.pem when it is not the same public key as
one of the ones in debian/pubkeys/*.pem (avoids shipping two copies of
the Debian pubkey)

this scheme requires standard locations for the private key. I would
suggest either ~/.debian-wireless-regdb.priv.pem or
debian-wireless-regdb.priv.pem in the package build directory.

>>> It is possible for users to add more public keys to the CRDA  pubkeys
>>> dir and build their own wireless-regdb using their own private key.
>> The above simplification makes this much easier.
> Not sure what you mean, but the idea with the pubkeys directory

The above scheme would allow users who apt-get source wireless-regdb,
edit db.txt, debuild, debi to automatically trust their own key, as
well as trusting Debian's key and the upstream key.

I wonder if any of this would be even remotely acceptable to
regulatory authorities.



Reply to: