Originally posted by shmerl
View Post
(a) this is hardware enablement, and something that every CrOS/android/etc device vendor would add downstream if it wasn't supported upstream. I'd prefer more code upstream where it gets proper review, security audits (ie. not is HCDP "uncrackable" but "is there a potential buffer overflow in that code"), etc. Is it better to later discover a CVE effecting millions of devices because of code device vendors maintained downstream effecting potentially even users not using DRM content? Or to get the code upstream and more eyes on it? I'm not saying to accept crap code upstream, but we should try to get it upstream (and if it was crap, refine it to the point that it isn't and it can be accepted upstream).
(b) I don't really see a downside.. if you aren't a fan of DRM then don't buy/consume DRM content. It's not like this is adding some closed src blob to the kernel or something like that.. it is adding a feature, not compelling anyone to use that feature.
(c) perhaps a kconfig option or module param to disable HDCP support would perhaps be a reasonable compromise. Either way, more downstream device kernel code is the worst of both worlds.
Leave a comment: