I skimmed the article, but one thing I didn't get is whether this is just a version difference (i.e., ChromeOS is on a different version of glibc), or is ChromeOS on a hard fork that will never reconcile with upstream ? If it's the former, it should resolve in due course; not so much for the latter.
It's the same code (presumably) but Chrome OS's version was compiled with metadata that said it was running on Chrome OS and Linux's version was compiled with metadata that said it was running on Linux. And that metadata is later embedded into the license request which Xfinity's servers check.
Of course, that's just my assumption from what I understand. I can't verify anything due to how obfuscated Widevine is. But due to how long-lived this problem has been, the two Widevine versions having the exact same version number (4.10.2557.0), and that everything else Widevine-wise works, I'm inclined to believe that this is intentional.
I understood that part; I meant whether running the ChromeOS widewine library on regular distributions is just a version difference in glibc, which would go away with time making the article's hack unnecessary in the future.
I see what you mean! I guess it depends on when Google updates to glibc v2.36, presumably they then would just include the DT_RELR version dependency on their binaries rather than unnecessarily patching glibc. Who knows how long that will take though since glibc v2.36 just came out a few months ago.
