Comment # 18 on bug 1173158 from Stefan Dirsch

(In reply to Martin Wilck from comment #17)
> (In reply to Stefan Dirsch from comment #9)
> 
> > If you believe it's easy send me a patch. For me it won't be easy at all.
> > The build scripts are non-interactive, so I don't see where one can add the
> > user interaction for accepting to add a generated custom key. I don't know
> > anything about an existing infrastructure for doing this and I don't
> > understand the comments in #1173115 at all.
> 
> It's indeed not easy. We could use a key stored in a standard location on
> the user's system. However, at the very least the build procedure should
> allow to enter the pass phrase for the key in a secure manner. Otherwise the
> secret key would need to be stored unencrypted on the target system, which
> would forfeit the use of secure boot, or a locked-down kernel, almost
> entirely.

I haven't looked deeper into this, but this were my first thoughts as well. I
think the idea was to sign the module with the first boot after installing it
in a still to be developed interactive mode. Technical ideas. No idea. 

> It would be much better to have a real KMP built with binary, signed
> modules, like we do it for OSS KMPs on OBS. That's obviously a legal problem
> for us. Maybe it would be possible to do it on pacman?

Better don't talk with legal about such ideas. ;-)

> Alternatively, there could be a way to transform the Nvidia pseudo-KMP into
> a real KMP *by the user*. The user could run this procedure on some
> particularly protected system, and distribute the generated KMP plus the
> associated cert to the systems in his data center.

Which then may break with the first kernel update. Yes, a kernel update
triggers a rebuild and reinstallation of the module.