It seems 16 is the more common limit on moderm OEM Crypto API systems (at least L1). It's also a more reasonable limit.
This also encourages people to .close() their session more. It also makes it quicker to notice if a codebase is forgetting to do a .close() call somewhere as you will reach the limit faster and easier now.
In normal use cases, a limit of 16 sessions will not be a problem as long as the sessions are being closed correctly.
This is for less effort to use the Service Certificate later on. We have no reason to keep the SignedMessage shell as it's just a way to send it as a message from License Acquisition APIs.
The logic of parsing the session's stored service cert to get the provider_id was wrong. It assumed it was a SignedDrmCertificate, when in reality it was a SignedMessage containing a SignedDrmCertificate.
It would also panic if you try to remove a certificate when none was set.
This is so you don't have to do e.g., `from pywidevine.pssh import PSSH` and instead can do `from pywidevine import PSSH`. You can still do it the other way, but now you have the choice.
This is required for cases like Google's testing DASH manifests, e.g., 'tears' MPD. It assumes the Key ID as a number, which can support up to 16 bytes in this fashion (therefore technically 15 in our scenario as 16 byte Key_IDs can load normally).
Fixes#13
There's no need for it. The image isn't even done particularly well. It's too specific to a browser scenario with some information not properly reflected/explained in the legend.
I have no reason to try make my own or look for an alternative. If someone is particularly interested they can look online for more or less broad explanations as they see fit.
This is to fix some security vulnerabilities. The main dependency locking this to 4.8.0 for so long was pycaption, which was updated to support 4.9.1 in v2.1.0.
This ensures that a partially parsing input (because of optional flags in the proto) does not get past any verification checks.
This prevents issues like an invalid License Challenging from getting an exception later down the line, as well as possibility of it also passing that check by pure luck, resulting in hard to debug issues.
The main change is that it isn't stored as 16-bytes. Effectively not stored like it realistically probably meant to be. It's instead stored as a hex string that was then encoded to bytes (32 data is now taken up).
But I've also improved the comments about my research for the first half of the request ID. This research is likely still incomplete as I'm just not fully sure about the randomness of bytes 5-8.
