On Mon, Jun 19, 2017 at 09:41:07PM +0200, Luis R. Rodriguez wrote: > On Mon, Jun 19, 2017 at 09:33:16AM +0200, Johannes Berg wrote: > > On Sat, 2017-06-17 at 21:38 +0200, Greg KH wrote: > > > > > But we don't accept kernel patches for some mythical future option > > > that might be happening some time in the future. Heck, I'm still not > > > convinced that firmware signing isn't anything more than just some > > > snakeoil in the first place! > > > > I for one really want the "firmware" signing, because I want to load > > the regulatory database through this API, and > > This was my original goal as well... and it was also one of the reasons why > the API name change would be much better reflective of future possible uses. > > > But honestly, I've been waiting for years for that now and started > > looking at what it would take to hand-implement that on top of the > > existing firmware API. Probably not all that much. > > I had proposed changes to do just this long ago, without any new *API*, so > we'd > support firmware signing just as we do with module signing. Simple! > > It was during these discussions that we realized we actually *wanted* to have > the option to always specify requests with specific signing requirements from > the start, as such a flexible API became a prerequisite and so I prioritized > that work first. > > Lets not ignore previous work and prior discussions then, the last effort on > this > front was by AKASHI, and it'd be greatly appreciated if the topic of firmware > signing was specifically addressed on that thread there [0].
+1 I always appreciate any comments from those who are for and against my patch (or firmware signing in general) as well. -Takahiro AKASHI > [0] https://lkml.kernel.org/r/20170526030609.1414-1-takahiro.aka...@linaro.org > > Luis
