Bug 484982 - regulatory.bin is signed with a random self-generated key
regulatory.bin is signed with a random self-generated key
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: crda (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-10 18:01 EST by Pavel Roskin
Modified: 2017-03-07 01:42 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-20 15:06:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pavel Roskin 2009-02-10 18:01:03 EST
Description of problem:
Compiling crda from sources fails if the crda package is installed

Version-Release number of selected component (if applicable):
crda-1.0.1_2009.01.30-4.fc10

How reproducible:
Always

Steps to Reproduce:
1. yum install crda
2. git clone git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git
3. cd crda
4. make
  
Actual results:
  GEN  keys-gcrypt.c
  CC   reglib.o
  CC   crda.o
  LD   crda
  CC   intersect.o
  CC   print-regdom.o
  LD   intersect
  CC   regdbdump.o
  LD   regdbdump
  CHK  /usr/lib/crda/regulatory.bin
Database signature verification failed.
make: *** [verify] Error 234

Expected results:
make succeeds

Additional info:
The spec file for crda removes John Linville's key and generates a new key.  That key is used to sign the database.  The key is different every time.  The public key is not even distributed with the package.

The simplest solution would be to leave regulatory.bin as is, provided that it passes verification.

Another solution would be to use a special Red Hat key and include the public key with the package.  That would allow Red Hat to change regulatory information without asking John.  The crda sources could eventually include keys of popular authorities, including Red Hat.

Or maybe we could have a Linux certification authority that would sign the database.

The most radical solution would be to have parts of the database signed by the responsible authorities.  That is, the US section would be signed by an FCC representative.  If the authority refuses to act, then a substitute signature by the Linux certification authority could be used.
Comment 1 John W. Linville 2009-02-11 14:44:21 EST
The build failure is really more of a CRDA upstream makefile issue.  More precisely, it could be avoided by building CRDA like this:

   make REG_BIN=/path/to/upstream/regulatory.bin

Regarding the issue of recognizing the upstream wireless-regdb key in the Fedora crda package, I'm not sure what the best answer is.  I removed the key in the crda package out of my own (possibly flawed) interpretation of Fedora policy/tradition.  I wanted to avoid having someone demand the release of the upstream private key due to some misguided license interpretation.  Of course the CRDA license is not GPL, so maybe that is unrealistic.

I'll copy Spot and notting to see if they have any not-quite-legal opinions on what should be done.  Personally I neither see the need to recognize that key in Fedora nor do I see any big downside to doing so.
Comment 2 Bill Nottingham 2009-02-11 14:51:59 EST
I don't see an issue with using the generated & thrown out key myself (although we should obviously fix it so it can build while a version is installed on the system)
Comment 3 Tom "spot" Callaway 2009-02-11 14:57:38 EST
I can't see any license interpretation that would require you to give up your private key, even if the public key was licensed GPL.
Comment 4 John W. Linville 2009-02-12 13:38:03 EST
With Fedora's blessing I'd be happy to build the package to accept the upstream wireless-regdb.  If I do that, it probably makes sense to build crda and wireless-regdb separately.  Thoughts?
Comment 5 Tom "spot" Callaway 2009-02-12 13:52:07 EST
You're gonna need to explain this to me before I bless anything. What do you want to do exactly?
Comment 6 John W. Linville 2009-02-13 14:47:17 EST
Spot, let me back-up and review...

The CRDA program is a udev helper whose job is to feed the kernel a set of regulatory rules for usage of radio spectrum for a specified regulatory domain (e.g. "US", "JP", etc).  It makes use of a binary database that is optionally(?) signed so that the CRDA binary can determine whether or not it trusts the authenticity of the regulatory data.  The CRDA code can accomodate multiple trusted keys in order to support multiple sources of authoritative regulatory data.

Upstream CRDA is maintained separately from the regualtory database.  The upstream CRDA tree recognizes a public key which is paired with a private key that I hold.  The wireless-regdb project maintains a regulatory.bin file that is built from sources within that project and which is signed with the private key.  Optionally it can generate a new key pair and sign the regulatory data with the new key instead.

Today's crda package in Fedora contains sources from both the upstream CRDA project and the upstream wireless-regdb project.  The RPM spec file causes the build to generate a new key pair and sign the regulatory data with that private key.  It also removes recognition of the upstream key from CRDA, so only the key generated during the build is recognized as authoritative.

So, two changes are possible.  One change would be to recognize the upstream key as authoritative either solely or as well as the build-generated key.  This would allow (unpackaged) updates of the regulatory.bin file from the upstream project outside of the Fedora update process.  The other change would be to split the current Fedora crda package into two packages, one for each of the CRDA and wireless-regdb upstream projects.  This would allow for the two components to be updated independently.  The second option is impossible (or at least impractical?) unless a specific key (probably the key I hold upstream) is used for signing the regulatory data.

The CRDA and wireless-regdb projects are both fairly small and I do not predict lots of churn with them (at least after some initial settling).  So, I don't see a big impetus for these changes.  OTOH, if users would prefer to use the upstream-signed regulatory data then I'm all for it.

Does that clarify the situation?  If not, then feel free to ask... :-)
Comment 7 Tom "spot" Callaway 2009-02-13 15:02:31 EST
Are you asking if we can ship that prebuilt binary in Fedora? Or do you want to use it for key signing? Still not sure I understand what you want to do here.
Comment 8 John W. Linville 2009-02-13 15:39:30 EST
Let me try to clarify the two questions. :-)

1) Can I build CRDA to include the upstream public key so that upstream binary regulatory.bin files work with the (built from source) crda binary shipped in Fedora.

2) If #1 is acceptable, then can we simply ship the upstream binary regulatory.bin file and not use a build-generated key at all?
Comment 9 Tom "spot" Callaway 2009-02-13 15:43:54 EST
1) I think this is fine.

2) No. You cannot ship prebuilt binaries.
Comment 10 Pavel Roskin 2009-02-13 15:51:57 EST
Can we make an exception for prebuilt binaries if they can be proven (at the package build time) to have originated from the sources in the package?  It's not like Fedora will need to patch regulatory.bin on its own.
Comment 11 Tom "spot" Callaway 2009-02-13 16:00:26 EST
(In reply to comment #10)
> Can we make an exception for prebuilt binaries if they can be proven (at the
> package build time) to have originated from the sources in the package?  It's
> not like Fedora will need to patch regulatory.bin on its own.

Nope. We don't trust what we don't build. The fact that it is in the tarball we got from upstream means nothing. We can audit the source code, we have no way to audit that the binary in a tarball is safe.
Comment 12 Pavel Roskin 2009-02-13 16:13:58 EST
The need to audit the binary can be satisfied.  The signature is appended at the end of regulatory.bin.  It's possible to build an unsigned regulatory.bin and compare it to the signed one.

$ ./db2bin.py regulatory.bin.unsigned db.txt
$ cmp -l regulatory.bin.unsigned regulatory.bin

If there is no difference except that regulatory.bin is longer, we should be fine.
Comment 13 Tom "spot" Callaway 2009-02-13 16:25:50 EST
(In reply to comment #12)

Sorry. We're not shipping prebuilt binaries.
Comment 14 John W. Linville 2009-02-16 16:36:19 EST
Now recognizing upstream key, still rebuilding regulatory.bin and signing with our own build-generated key.
Comment 15 Dilip Dangi 2017-03-07 00:54:29 EST
Excuse me: Pavel Roskin and other friends who have already fixed the problem
i need your help


can you provide me the stepwise solution through any tutorial or any video
 
because i am new in kali linux 

my problem was same as yours

  

  GEN  keys-gcrypt.c
  CC   reglib.o
  CC   crda.o
  LD   crda
  CC   intersect.o
  CC   print-regdom.o
  LD   intersect
  CC   regdbdump.o
  LD   regdbdump
  CHK  /usr/lib/crda/regulatory.bin
Database signature verification failed.
make: *** [verify] Error 234
Comment 16 Pavel Roskin 2017-03-07 01:42:00 EST
This is not an appropriate place to provide support for other distributions. I would not go to the bugtracker of another distro to get help with Fedora.

Note You need to log in before you can comment on or make changes to this bug.