From: Kel Modderman <kel@otaku42.de>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] crda: do not embed crypto data when USE_OPENSSL=1
Date: Fri, 5 Mar 2010 12:00:01 +1000 [thread overview]
Message-ID: <201003051200.01511.kel@otaku42.de> (raw)
In-Reply-To: <201003051156.11922.kel@otaku42.de>
On Friday 05 March 2010 11:56:11 Kel Modderman wrote:
> On Friday 05 March 2010 11:37:22 John W. Linville wrote:
> > On Fri, Mar 05, 2010 at 10:27:03AM +1000, Kel Modderman wrote:
> > > On Friday 05 March 2010 01:31:28 John W. Linville wrote:
> > > > On Fri, Mar 05, 2010 at 12:08:50AM +1000, Kel Modderman wrote:
> > > > > When USE_OPENSSL=1 do not embed crypto data into binary, use the PUBKEY_DIR
> > > > > variable just as it is when USE_GCRYPT=1 and just load certs from PUBKEY_DIR
> > > > > for signature verification at runtime. Remove ssl support from
> > > > > utils/key2pub.py.
> > > > >
> > > > > This allows wireless-regdb to be built from source and upgraded independently
> > > > > of crda and is _crucial_ for distributions who want to build their own
> > > > > regulatory.bin.
> > > >
> > > > I don't understand -- isn't this possible already?
> > >
> > > No.
> >
> > Perhaps you could use a few more words? It seems to me that what
> > limits you is the policies of some distributions. Certainly crda
> > and wireless-regdb can be maintained separately so long as the key
> > doesn't change between builds or with alternate keys installed in
> > the proper locations. Am I missing something?
>
> Yes you are missing something. Its not the policy of my distribution which
> is limiting its the design of the crda/wireless-regdb build systems.
>
> Now that openssl support allows reading pubkeys at runtime, the embedding
> of crypto data into binaries can be totally removed when built with openssl.
>
> wireless-regdb can be built from source, when it does so it generates a new
> custom key which is installed to /lib/crda/pubkeys/<key>. Your key is also
> installed here, oh but hang on, its also embedded into the binary so why bother
> installing it at all? Alright, so we can manually move our custom generated
> key from /lib/crda/pubkeys/<key> to /etc/wireless-regdb/pubkeys/<key> and things
> will probably be okay next time we build wireless-regdb and upgrade it
> independently of crda, except for:
> 1. we now have /lib/crda/pubkeys/linville.pub.pem for no reason at all
> 2. the distribution is installing to /etc/wireless-regdb/pubkeys/ which should
> be reserved for the admin
> 3. you're maintaining a bunch of useless code which embeds openssl data into
> binaries when you do not have to
4. if your key changes, and we have built and upgraded wireless-regdb and not
crda then the embedded crypto data and /lib/crda/pubkeys/linville.pub.pem
won't help
>
> These 3 points is what my patch attempts to address.
4 points
Thanks, Kel.
next prev parent reply other threads:[~2010-03-05 2:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-04 14:08 [PATCH] crda: do not embed crypto data when USE_OPENSSL=1 Kel Modderman
2010-03-04 15:31 ` John W. Linville
2010-03-05 0:27 ` Kel Modderman
2010-03-05 1:37 ` John W. Linville
2010-03-05 1:56 ` Kel Modderman
2010-03-05 2:00 ` Kel Modderman [this message]
2010-03-05 4:08 ` John W. Linville
2010-03-05 14:59 ` Kel Modderman
2010-03-08 8:08 ` Johannes Berg
2010-03-21 10:46 ` Kel Modderman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201003051200.01511.kel@otaku42.de \
--to=kel@otaku42.de \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).