Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-06-16T22:40:36Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2105Make config option (-c) optional?2018-06-16T22:40:36ZMarvin ScholzMake config option (-c) optional?> Should icecast automatically (i.e. without needing -c) look for the config file in /etc/icecast.xml or something?> Should icecast automatically (i.e. without needing -c) look for the config file in /etc/icecast.xml or something?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2104Check: Bytes sent and time listening might be broken?2018-10-04T10:54:41ZMarvin ScholzCheck: Bytes sent and time listening might be broken?> logging - bytes send and time listening may both be broken?
As mentioned in the TODO file, we should check this.
> logging - bytes send and time listening may both be broken?
As mentioned in the TODO file, we should check this.
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2102Make strcmp in main.c#_start_logging explicit2018-03-06T12:49:47ZMicheil SmithMake strcmp in main.c#_start_logging explicitCurrently the don't pipe to standard output options are in the else branch, because of usage of `strcmp` such as `if ( strcmp(a, b) ) { `.
This gist https://gist.github.com/miksago/cfb3f41784bff197facc includes changes to make the comp...Currently the don't pipe to standard output options are in the else branch, because of usage of `strcmp` such as `if ( strcmp(a, b) ) { `.
This gist https://gist.github.com/miksago/cfb3f41784bff197facc includes changes to make the comparison of strings explicit as well as changes the logic to be:
```
if config->access_log == '-'; then
handle standard output
else
handle logging
```
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2099Review how Icecast binds to sockets (IPv6/IPv4)2022-03-07T10:07:56ZThomas B. RückerReview how Icecast binds to sockets (IPv6/IPv4)The current behaviour, as introduced after considerable research and discussion neeeds to be reviewed.
Either we should bind to *both* if no IP nor protocol is specified or we MUST document this better and change the default config to e...The current behaviour, as introduced after considerable research and discussion neeeds to be reviewed.
Either we should bind to *both* if no IP nor protocol is specified or we MUST document this better and change the default config to explicitly bind to both.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2098TAGs for comments in all icecast projects2018-03-06T12:49:47ZPhilipp SchafftTAGs for comments in all icecast projectsI suggest to define the following tags in comments for more easy finding stuff that needs to be reviewed or handled in future release. Those tags should be added as part of the coding style guide to define some standard for the Icecast p...I suggest to define the following tags in comments for more easy finding stuff that needs to be reviewed or handled in future release. Those tags should be added as part of the coding style guide to define some standard for the Icecast project and be used by all components handed by the project including but not limited to the Icecast server, Ices2 and the library subprojects. I'm unsure if/how it will match the stream directory subproject.
The following tags should be defined:
Actions:
- REVIEW: ask for a review of this.
- REWRITE: ask for a rewrite of this section.
- TODO: ask for implementation of a feature.
- FIXME: ask correcting an implementation.
- REMOVE: remove a block or feature.
- DOCUMENT: documentation for this block or feature is missing, incomplete or wrong and needs update.
Conditions:
- [BEFORE|AFTER|IN] RELEASE $version: This is relevant to release $version. $version can also be NEXT.
- [BEFORE|AFTER|IN] YEAR $yyyy: This is relevant to (4-digit) year $yyyy
Extra Tags:
- IMPORTANT: This is an important problem.
- SECURITY: This is security critical.
- LEAK: This leaks some resource (memory, file descriptors, ...).
Syntax:
```
/* [CONDITION[ CONDITION[...]]] [EXTRA TAGS] ACTION [#TICKET]: DESCRIPTION
* [LONG DESCRIPTION]
*/
```
Examples:
```
/* BEFORE RELEASE 2.5.3 REVIEW #1234: Should we convert A to B?
* A is according to standard REF0. This standard was superseded by
* standard REF1 which could be implemented with option B.
* This may break early clients of standard REF0 not being aware of SOMETHING.
*/
/* IN YEAR 2022 REWRITE: Change copyright statement as license expires. */
/* LEAK FIXME #1234: Fix case object can not be added to queue. */
/* BEFORE RELEASE NEXT IMPORTANT SECURITY FIXME #1234: Do not expose passwords on authentication failure of backend server */
/* AFTER RELEASE 2.5.3 REMOVE: Remove support for icecast 1.x style SOURCE requests */
```Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2097In <listener> in some tags are camelcase that should be converted to lowercase.2018-03-06T12:49:47ZPhilipp SchafftIn <listener> in some tags are camelcase that should be converted to lowercase.in <listener> the following tags are camelcase: <ID>, <IP>, <UserAgent> and <Connected>. Those should be converted to lower case.
XML tells that tag names are case sensitive.
This needs to be documented before we can change it and be cha...in <listener> the following tags are camelcase: <ID>, <IP>, <UserAgent> and <Connected>. Those should be converted to lower case.
XML tells that tag names are case sensitive.
This needs to be documented before we can change it and be changed with a major release. I suggest to document it as 'Parsers MUST be case insensitive for ALL tags in ANY admin/-command output.'
```
09:51 <+tbr> as a broad statement, I'd not expect this change to happen before 2.6
09:52 < ph3-der-loewe> I haven't thought about a timeline for that already.
09:52 < ph3-der-loewe> I'm fine with <= 3.0.0 :)
09:53 < ph3-der-loewe> with 3.0.0 the question that arise is if the interface still exist ;)
```
Please review this before 2.5 to check if we are on-track on this.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2096use setresuid()/setresgid() instead of setuid()/setgid()2018-03-06T12:49:47Zd26264b9use setresuid()/setresgid() instead of setuid()/setgid()We should be dropping privileges with setresuid()/setresgid() when requested as recommended by "Setuid Demystified" (http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf).
Also, chdir("/") after chroot() and actually check for pro...We should be dropping privileges with setresuid()/setresgid() when requested as recommended by "Setuid Demystified" (http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf).
Also, chdir("/") after chroot() and actually check for proper return values on both. This was modelled after OpenSSH's chroot() logic.
Tested on OpenBSD. Someone should try compiling/testing on Linux to verify. As far as I can tell, the proper syscalls are implemented on Linux as well.
```
--- src/main.c Mon May 5 18:29:06 2014
+++ src/main.c Thu Nov 27 18:55:34 2014
@@ -377,7 +377,7 @@
fprintf(stderr, "WARNING: Cannot change server root unless running as root.\n");
return;
}
- if(chroot(conf->base_dir))
+ if(chroot(conf->base_dir) == -1 || chdir("/") == -1)
{
fprintf(stderr,"WARNING: Couldn't change server root: %s\n", strerror(errno));
return;
@@ -398,7 +398,7 @@
}
if(uid != (uid_t)-1 && gid != (gid_t)-1) {
- if(!setgid(gid))
+ if(!setresgid(gid, gid, gid))
fprintf(stdout, "Changed groupid to %i.\n", (int)gid);
else
fprintf(stdout, "Error changing groupid: %s.\n", strerror(errno));
@@ -406,7 +406,7 @@
fprintf(stdout, "Changed supplementary groups based on user: %s.\n", conf->user);
else
fprintf(stdout, "Error changing supplementary groups: %s.\n", strerror(errno));
- if(!setuid(uid))
+ if(!setresuid(uid, uid, uid))
fprintf(stdout, "Changed userid to %i.\n", (int)uid);
else
fprintf(stdout, "Error changing userid: %s.\n", strerror(errno));
```
Philipp SchafftPhilipp Schaffthttps://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/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/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ücker