Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fixed: allow some basic HTTP headers to be passed on to ffmpeg #10402
Might I suggest a few more?
Just did a quick grep of a few ffmpeg/curl internet stream logs I had backed up for headers that I didn't see included here:
I am sure more will come up in due time
Thanks for all your hard work folks!
What's the purpose of whitelisting headers?
Case in point: It breaks Kodi addons by throwing out authentication-releated headers, like over here: hippojay/plugin.video.plexbmc#181.
In this case, whitelisting everything that starts with
There was a very long discussion on what headers to allow (see there original PR #10402) as initially no headers were allowed. The current implementation allows the most common headers. Although allowing all custom X- prefixed headers seems reasonable, I have doubts as the X- prefixed headers are officially deprecated (see https://tools.ietf.org/html/rfc6648). Let's wait and see what @FernetMenta thinks.
As @basrieter mentioned, this was done for good reasons. It is not about restricting the HTTP protocol but the mechanism Kodi provides to addons using its infrastructure. The past has shown that this can result into a security breach, sending sensitive data out in the wild. This mechanism lacks a method of identifying what in the provided url was really meant to be a header.
With growing number of addons we need to start discussion about how to deal with security. Maybe we should start introducing security settings that users can extra privileges to addons.
But it effectively is restricting the HTTP protocol.
If I want my plugin to misbehave then I easily can send relevant data as an URL parameter or in the request body. I can even encrypt it. There is no way for Kodi to check this, so claiming that restricting headers would have security implications is indefensible as a position.
I'm pretty sure that anecdotal evidence can be found where some plugin sent sensitive data via HTTP header, but it's easy to see that this change would do nothing to stop the author of such a plugin. In fact, in the particular issue that brought me here, the opposite is the case. The header in question is a server authentication token. Sending it as URL parameter would populate log files 1000-fold with that token and it would be easy to argue that not spamming logs the sensitive information has a positive effect on the user's security.
Anecdotal evidence can be found for and against, it's not good guidance. If this is an infrastructure method intended to underpin general communication in Kodi, then it should support HTML without making any assumptions. How headers are being used or even mis-used is completely orthogonal to the purpose of a function that implements the HTTP interface.
To employ a bad analogy, that's like restricting the steering wheel of a car so that drivers it can't make left turns anymore and then justifying it by saying that left turns are statistically more likely to cause accidents therefore it's for the driver's safety and three rights make a left anyway so it's not a bad move. It's still a bad move.
While I understand and partially agree with the spirit of the Kodi Dev teams reasons for the restrictions.
I guess my ultimate take is that most folks already have a firewall, anti-virus and anti-malware (etc. etc.) installed on their system for protection.
So how about a compromise?
Would you consider adding an advanced setting switch to allow all headers?
Then you don't have to play net and protocol nanny for those that understand and assume the risks?
I would hope this sort of solution would be how most things should be solved when it is decided to arbitrarily impose restrictions for the masses but allow those that assume and understand the risks to remove the training wheels and drive like big boys.
I maintain the position that
I appreciate the fact that this has been in discussion for a while, even though I find it a bit odd that the discussion and also the code comments seem to focus around ffmpeg, which hardly is the only use case here.
Maybe I am missing an important, justifying point. But so far I am not convinced that this really is a useful change and think that rolling it back entirely does not have substantial drawbacks.