Bug 484982

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.

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)

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.

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?

You're gonna need to explain this to me before I bless anything. What do you want to do exactly?

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... :-)

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.

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?

1) I think this is fine.

2) No. You cannot ship prebuilt binaries.

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.

(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.

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.

(In reply to comment #12)

Sorry. We're not shipping prebuilt binaries.

Now recognizing upstream key, still rebuilding regulatory.bin and signing with our own build-generated key.

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

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.