Icecast - Oct 2014 - BUG ? - Metadata/tags NOT UPDATING - Python IceCast 2.3.2[3]

On 09/30/2014 10:15 PM, Dean Sauer wrote:
> On Tue, 05 Aug 2014 21:14:51 +0000, Thomas B. R?cker wrote:
>
>> Please note that 2.3.2 has an enormous amount of known bugs and some
>> security issues. I do not know which patches are applied by the
>> distributions to potentially mitigate some of the security issues.
> Don't know, but I've not had issues with 2.3.2 on another server
for over
> 3+ years. We moved servers and the host put 2.3.3 on it. Till some 
> software development noticed an issue in regards to updating metadata/
> tags... which see below is a deal breaker for us.
>
>> Distribution packages and their versions:
>> http://packages.ubuntu.com/search?keywords=icecast2
> 2.3.3 is the only thing for Ubuntu, but based on further reading to your 
> reply 2.3.3 and 2.4.x and forward may be an issue for us...at least. 
>
>> Latest stable Icecast *buntu packages for the two LTS releases:
>> http://download.opensuse.org/repositories/home:/dm8tbr/xUbuntu_12.04/
>> http://download.opensuse.org/repositories/home:/dm8tbr/xUbuntu_14.04/
> Thanks but that appears to be source to compile.. 
No that's a repository with binary packages and source packages.
The Open Build Service produces packages for many distributions from one
build definition and source code. It's a very useful thing, that allows
me to have packages of current and beta Icecast, for most mainstream
distributions available and supported.

To add the repository to your sources.list or list snippet:
deb http://download.opensuse.org/repositories/home:/dm8tbr/xUbuntu_12.04/ ./
or
deb http://download.opensuse.org/repositories/home:/dm8tbr/xUbuntu_14.04/ ./

For more details:
https://build.opensuse.org/package/show/home:dm8tbr/icecast

You can consider them official as I'm building them as the Icecast
maintainer.

>> Returning 200 instead of 403, in this case, might be a bug. This would
>> need further investigation. Thanks for bringing this to my attention.
> Yeah.. under 2.3.3 it will take it, give a 200, and nothing happens due 
> to the "IP Block Problem." 
That sounds like a bug that we should fix for 2.4.1 then.
For parties interested to track this:
https://trac.xiph.org/ticket/2037

> We have since rolled back to 2.3.2 to keep this at bay.
As long as you are aware of the security implications.
This is mainly CVE-2011-4612.
http://icecast.org/news/

>> I don't remember if we change log verbosity on a reload.
>> Surely you do have a test environment that you could use for your
>> testing purposes?
> I can setup a VM with a test server in it, but if I have the coders I ask 
> them.
>
>
>> http://icecast.org/news/icecast-release-2_3_3/
>> "Only allow raw metadata updates from same IP as connected source
>> (unless user is admin). This addresses broken client software that
>> issues updates without being connected."
>> If you use 2.3.3, then using admin credentials is your only option to
>> update metadata from a different IP address.
>> Unless you patch and rebuild Icecast.
>>
> Is this the case > 2.3.2? Thus 2.4.x and forward will have this problem?
>
> While I understand where your coming from, this poses a problem for us. 
We did not expect people to be (ab)using this feature in this way. Now
that we're aware of it we should consider making this configurable. What
this would mean that there would be a global configuration switch to
consciously enable the old behaviour or a per mount point override.
We're not going to revert the change as a whole, as it was addressing a
much more common problem.

While this is not a complicated thing, I probably won't have the time to
work on this for a while. If someone wants to see this in 2.4.1, then
I'd would suggest contacting Philipp. I'm sure he'd make the time if
someone would be willing to sponsor the patch development.


Best regards

Thomas B. Ruecker