Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:47Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2089[duplicate] icecast sends output of <on-connect> script to source client2018-03-06T12:49:47ZSven Herzberg[duplicate] icecast sends output of <on-connect> script to source clientPlease look at #2087 instead.
----
Using the on-connect script from #2087, a client which does not close the connection immediately after receiving the 200 response, has a chance of reading “stdout” after stopping to send any data.
If...Please look at #2087 instead.
----
Using the on-connect script from #2087, a client which does not close the connection immediately after receiving the 200 response, has a chance of reading “stdout” after stopping to send any data.
If this is unintentional, this data should end up in e.g. the `<errorlog>` target.
If this is intentional, the length of the data should be indicated by a `Content-Length` header, or should be properly encoded as `Transfer-Encoding: chunked` (which would then be required as a header in the response).Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2088accept data with “Transfer-Encoding: chunked”2018-03-06T12:49:47ZSven Herzbergaccept data with “Transfer-Encoding: chunked”Many HTTP frameworks will automatically encode data streams using the aforementioned method. I propose this behavior for Icecast:
* check if the protocol is not `HTTP/1.1` or there is no `Transfer-Encoding` header, continue as in the pa...Many HTTP frameworks will automatically encode data streams using the aforementioned method. I propose this behavior for Icecast:
* check if the protocol is not `HTTP/1.1` or there is no `Transfer-Encoding` header, continue as in the past (i.e. assume `identity` encoding)
* if the `Transfer-Encoding` header is present and it is `identity`, continue as in the past
* if the `Transfer-Encoding` header is present and it is `chunked`, accept the data and strip the encoding information both from the output stream and from the dumpfile
* if the `Transfer-Encoding` header is present and has a different value, terminate the request with 501 (Unimplemented) and provide an HTTP response body listing the supported encodings (in case developers need to debug this).
That behavior in compliant with RFC2616 (Section 3.6) and RFC7230 (Section 3.3.1).Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2087icecast does not only write the stream data into the dumpfile2018-03-06T12:49:47ZSven Herzbergicecast does not only write the stream data into the dumpfileHow to reproduce:
Write a script (e.g. called “test-script.sh”) with this content and set the executable bit:
```
set -e
set -x
echo "stdout"
echo "stderr" >&2
```
Then specify that script in an mount point of the icecast configurat...How to reproduce:
Write a script (e.g. called “test-script.sh”) with this content and set the executable bit:
```
set -e
set -x
echo "stdout"
echo "stderr" >&2
```
Then specify that script in an mount point of the icecast configuration like this (I have this in my mount point defaults):
```
<on-connect>/path/to/test-script.sh</on-connect>
```
The beginning of the dump-file will look like this:
```
# hexdump -C /srv/icecast/test-stream/backup.mp3 | head
00000000 2b 20 65 63 68 6f 20 73 74 64 6f 75 74 0a 2b 20 |+ echo stdout.+ |
00000010 65 63 68 6f 20 73 74 64 65 72 72 0a 73 74 64 65 |echo stderr.stde|
00000020 72 72 0a 2b 20 65 78 69 74 20 30 0a […] |rr.+ exit 0.[…]|
```
This makes the dumpfiles difficult to use as backups of the stream data.
I think the `<errorlog>` target would be more a appropriate target for this output.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2086[PATCH] Send final status code only after the source data was received2018-03-06T12:49:47ZMarvin Scholz[PATCH] Send final status code only after the source data was receivedIcecasts new PUT support should comply with the HTTP protocol, currently this isn't the case since it sends the status line (`200 OK`) right after the source clients connects, but should only send it at the end of the request. Error code...Icecasts new PUT support should comply with the HTTP protocol, currently this isn't the case since it sends the status line (`200 OK`) right after the source clients connects, but should only send it at the end of the request. Error codes can be sent earlier, since they indicate that transmission of data is finished.
> An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body.
With the success code 200 (and others like 201) this is not the case, since it would indicate Success until all data is received which makes no sense.
If a source client needs a indicator when to start sending data, it should set the `Expect: 100-continue` header and wait for the `100 Continue` reply from the server.
Here is an example what Icecast currently sends:
```
> PUT /testsendung.mp3 HTTP/1.1
> Authorization: Basic REDACTED=
> Host: example.com:8001
> Accept: */*
> Content-Type: audio/ogg
> Ice-Public: 1
> Ice-Name: Teststream
> Ice-Description: This is just a simple test stream
> Ice-URL: http://example.org
> Ice-Genre: Rock
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
> [ Some stream data sent by client ]
< HTTP/1.0 200 OK
> [ More stream data sent by client ]
```
Instead Icecast should send:
```
> PUT /testsendung.mp3 HTTP/1.1
> Authorization: Basic REDACTED=
> Host: example.com:8001
> Accept: */*
> Content-Type: audio/ogg
> Ice-Public: 1
> Ice-Name: Teststream
> Ice-Description: This is just a simple test stream
> Ice-URL: http://example.org
> Ice-Genre: Rock
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
> [ Stream data sent by client ]
< HTTP/1.1 200 OK
< Content-Length: 0
< Connection: close
<
* Closing connection 0
```
(Additionally note that Icecast mixes HTTP Protocol)
This patch fixes the behavior so that it matches the second one. I am not completely sure if I fixed it the right way, since the file server internals are not 100% clear to me.
I marked it was critical since I think we should address this asap, so that (new) source clients do not start to rely on this (wrong) behavior.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2085Removal of <threadpool>2018-11-09T14:06:15ZPhilipp SchafftRemoval of <threadpool><threadpool> should be removed as it is no longer in use.
I suggest to add a ERROR level message on usage in 2.4.2 informing the user about this.
Then I suggest that we remove the setting completely in 2.5.0, not before in about one year.<threadpool> should be removed as it is no longer in use.
I suggest to add a ERROR level message on usage in 2.4.2 informing the user about this.
Then I suggest that we remove the setting completely in 2.5.0, not before in about one year.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2084Add support for ANSI streaming2021-10-26T09:40:29ZPhilipp SchafftAdd support for ANSI streamingStreaming in Text+ANSI Codes should be added to icecast. This would allow to to send shows of e.g. text adventures or other text games and applications.Streaming in Text+ANSI Codes should be added to icecast. This would allow to to send shows of e.g. text adventures or other text games and applications.Icecast 2.6https://gitlab.xiph.org/xiph/icecast-server/-/issues/2082Require content-type for PUT connections2018-03-06T12:49:47ZThomas B. RückerRequire content-type for PUT connectionsWe should only allow PUT connections if the content-type is explicitly set.
This will avoid breakage such as a source sending a ogg/vorbis stream, but not setting a content-type and then being mis-listed as "audio/mpeg" instead of "audio...We should only allow PUT connections if the content-type is explicitly set.
This will avoid breakage such as a source sending a ogg/vorbis stream, but not setting a content-type and then being mis-listed as "audio/mpeg" instead of "audio/ogg".
This will need to be made very clear in release notes and documentation, so that people are aware when writing new clients or porting old clients to the PUT protocol to properly set content-type.
We can't enforce this for SOURCE connections as there are simply too many broken clients out there.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2081Wrong duration value in access.log on mingw32 builds2018-03-06T12:49:47ZThomas B. RückerWrong duration value in access.log on mingw32 builds34678888 or such (jitter in the last 4-5 digits) for static files from the web interface that were served in under a second is rather unlikely.
On the mailing list someone reported also weird values in case of longer connections.
Teste...34678888 or such (jitter in the last 4-5 digits) for static files from the web interface that were served in under a second is rather unlikely.
On the mailing list someone reported also weird values in case of longer connections.
Tested on Windows 2012 R2Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2080Limit/Filter access types available through a listener socket2018-10-02T08:29:07ZThomas B. RückerLimit/Filter access types available through a listener socketOne thing that might be worth considering is to add another setting to listener sockets that would limit which requests are handled on that port.
Listener clients, POST/sources, admin, STATS, XSLT, static files - come to mind.
Especial...One thing that might be worth considering is to add another setting to listener sockets that would limit which requests are handled on that port.
Listener clients, POST/sources, admin, STATS, XSLT, static files - come to mind.
Especially in case of professional installations there is often the desire to limit exposure to potential attacks to a minimum.
That way there could be a listener client port on public IP, while all advanced functionality would only be available on a firewalled IP/port.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2077Stats data in iso8601 fields on mingw32 builds is wrong.2018-03-06T12:49:47ZThomas B. RückerStats data in iso8601 fields on mingw32 builds is wrong.We're using %z, which isn't consistent with other platforms. It depends on system configuration but could be a textual representation of the time zone or the time zone offset. The latter is what we want.
There is a workaround in our log...We're using %z, which isn't consistent with other platforms. It depends on system configuration but could be a textual representation of the time zone or the time zone offset. The latter is what we want.
There is a workaround in our logging code for this, which should be applied here too.Icecast 2.5.0https://gitlab.xiph.org/xiph/icecast-server/-/issues/2074symlink icecast docs into web dir during install2018-03-06T12:49:39ZThomas B. Rückersymlink icecast docs into web dir during installThis would make the docs much more discoverable for the average user.
We could then simply link to them from the status page and the admin pages.
Docs are already HTML as we also expose them through http://icecast.org/docs/ for each ver...This would make the docs much more discoverable for the average user.
We could then simply link to them from the status page and the admin pages.
Docs are already HTML as we also expose them through http://icecast.org/docs/ for each version
On Windows it would be a full copy instead.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2073Turn on Forward Secrecy in openSSL support2022-03-21T09:33:34ZThomas B. RückerTurn on Forward Secrecy in openSSL supportThis would further improve security in case of HTTPS usage.
This will need a patch to configure the curve to be used.
cf.
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
https://github.com/bumptech/stud/pull/61/...This would further improve security in case of HTTPS usage.
This will need a patch to configure the curve to be used.
cf.
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
https://github.com/bumptech/stud/pull/61/filesIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2072Update default SSL cipher list to be more secure2018-03-06T12:49:47ZThomas B. RückerUpdate default SSL cipher list to be more secureCurrently: "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM"
Proposed: "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:
DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"
This was taken from: https://...Currently: "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM"
Proposed: "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:
DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"
This was taken from: https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/#fnref2 (scroll up 2 lines)
I've tested this successfully against https://www.ssllabs.com/ssltest/ in combination with the patch for #2071. The only OS/Browser combination failing is: IE 6 / XPIcecast 2.4.1Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2071disable SSLv3 and SSL compression explicitly2018-03-06T12:49:47ZThomas B. Rückerdisable SSLv3 and SSL compression explicitly** SSLv3 is broken.
* Disabling compression mitigates the CRIME attack.
see attached patch** SSLv3 is broken.
* Disabling compression mitigates the CRIME attack.
see attached patchIcecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2070openSSL configuration overhaul in Icecast2023-01-03T10:26:01ZThomas B. RückeropenSSL configuration overhaul in IcecastI'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's sy...I'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's systems, but still we should do our part to prevent bad things from happening.
There will be dependent tickets filed for certain aspects.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2063Go through compiler warnings and such2018-03-06T12:49:47ZThomas B. RückerGo through compiler warnings and suchThere are a couple build time warnings from e.g. gcc that might need to be addressed.
This is the top level ticket for such issues. If you create tickets about build time warnings, please put the ID of this ticket: #2063 into the "Paren...There are a couple build time warnings from e.g. gcc that might need to be addressed.
This is the top level ticket for such issues. If you create tickets about build time warnings, please put the ID of this ticket: #2063 into the "Parent Tickets" field of your ticket.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2061Investigate: Relay not recovering2021-10-30T09:42:21ZMarvin ScholzInvestigate: Relay not recoveringAs reported in IRC by AAA_awright, a relay doesn't seem to reconnect if the source mount times out, see attached log. This happened with Icecast 2.3.3, we should check that this does not happen with 2.4.0, it should recover if the source...As reported in IRC by AAA_awright, a relay doesn't seem to reconnect if the source mount times out, see attached log. This happened with Icecast 2.3.3, we should check that this does not happen with 2.4.0, it should recover if the source mountpoint is back.
> I had a problem where one of my relays has stopped relaying, and I couldn't bring it back up without a restart. It's only playing the fallback. It reloads the relay data from the master server, but ignores it somehow. It honors me changing the refresh interval in the config file and everything.
> The event seems to happen at 2014-10-12 05:41:13, and it never recovers or mentions the stream again
> If it helps, I don't see another "checking master stream list" for another 15 minutes: [2014-10-12 06:09:20] DBUG slave/_slave_thread checking master stream list
> Before 05:41, it occurs reliably every 120 secondsThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2059[PATCH] Better code style consistency2018-03-06T12:49:47ZMarvin Scholz[PATCH] Better code style consistencyThis patch makes the overall code style more consistent.This patch makes the overall code style more consistent.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2058[PATCH] Replace logging macros2018-03-06T12:49:47ZMarvin Scholz[PATCH] Replace logging macrosReplace the old logging macros with variadic argument macros.
`ERROR0`, `ERROR1`, `ERROR2`, `ERROR3`, `ERROR4` are replaced with `LOG_ERROR`
`WARN0`, `WARN1`, `WARN2`, `WARN3` are replaced with `LOG_WARN`
`INFO0`, `INFO1`, `INFO2`, `INF...Replace the old logging macros with variadic argument macros.
`ERROR0`, `ERROR1`, `ERROR2`, `ERROR3`, `ERROR4` are replaced with `LOG_ERROR`
`WARN0`, `WARN1`, `WARN2`, `WARN3` are replaced with `LOG_WARN`
`INFO0`, `INFO1`, `INFO2`, `INFO3` are replaced with `LOG_INFO`
`DEBUG0`, `DEBUG1`, `DEBUG2`, `DEBUG3`, `DEBUG4` are replaced with `LOG_DEBUG`
Additionally a bit formatting was done, to match common c code style (only where it really shouted for attention, while looking through the files)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2057Rewrite HTTP handling to correctly implement HTTP/1.12018-11-09T14:06:15ZMarvin ScholzRewrite HTTP handling to correctly implement HTTP/1.1Icecast should support HTTP/1.1 especially since we already do this partially for PUT support.
HEAD should probably be added too, since it might be useful and some players maybe do it to check content-type, length…
Additionally to compl...Icecast should support HTTP/1.1 especially since we already do this partially for PUT support.
HEAD should probably be added too, since it might be useful and some players maybe do it to check content-type, length…
Additionally to completely support PUT and stay in spec we need to support chunked encoding.Icecast 2.6Thomas B. RückerThomas B. Rücker