Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:49:38Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2094YP protocol documentation / revision2018-03-06T12:49:38ZThomas B. RückerYP protocol documentation / revisionWe should document the currently used YP protocol, old docs might be available but are outdated.
As we'll have to introduce a few changes we should rethink some protocol aspects while we document it.
Collaborative wiki page is at https...We should document the currently used YP protocol, old docs might be available but are outdated.
As we'll have to introduce a few changes we should rethink some protocol aspects while we document it.
Collaborative wiki page is at https://wiki.xiph.org/Icecast/YP-protocol-v2Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://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/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/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/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/2100Document icecast access log format in docs2018-03-06T12:49:38ZThomas B. RückerDocument icecast access log format in docswe should explain it, especially the last field that adds on top of Apache "combined" type output and signifies connection duration in seconds.
Also mentioning that we do NOT log the amount of data sent by a source client due to adherin...we should explain it, especially the last field that adds on top of Apache "combined" type output and signifies connection duration in seconds.
Also mentioning that we do NOT log the amount of data sent by a source client due to adhering to convention "bytes _sent_".Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2101Verify if on-connect (events) are still impossible on windows2018-03-06T12:49:38ZThomas B. RückerVerify if on-connect (events) are still impossible on windowsWe migrated to mingw32, I suspect it might now be either trivial or easy to fork a script (.bat). We migrated to mingw32, I suspect it might now be either trivial or easy to fork a script (.bat). Icecast 2.6Stephan JauernickStephan Jauernickhttps://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/2103Clarify default setting of logarchive2018-03-06T12:49:38ZMicheil SmithClarify default setting of logarchiveCurrently no default setting is in place for logarchive in the configuration, it's just by chance that the default is that it's off, due to how the internals of log.c work.Currently no default setting is in place for logarchive in the configuration, it's just by chance that the default is that it's off, due to how the internals of log.c work.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/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/2106Pull vorbis comments (metadata) and send to stats2018-03-06T12:49:47ZMarvin ScholzPull vorbis comments (metadata) and send to stats> Pull out vorbis comments and send to stats. This seems to be being done, but it isn't working right.
Icecast should pull [vorbis comments](http://de.wikipedia.org/wiki/Vorbis_comment) and make them available in stats.> Pull out vorbis comments and send to stats. This seems to be being done, but it isn't working right.
Icecast should pull [vorbis comments](http://de.wikipedia.org/wiki/Vorbis_comment) and make them available in stats.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2107Provide a way for YP Dirs to check streams2020-10-15T11:58:06ZMarvin ScholzProvide a way for YP Dirs to check streams>directory server GUID checks
>
>directory server does GET /GUID-asldjfasldfjalsdkfjasldkfj HTTP/1.0
>and either gets a 404 if it's wrong, or a 200 if it's correct.
As suggested already in early drafts of the YP Protocol, there should b...>directory server GUID checks
>
>directory server does GET /GUID-asldjfasldfjalsdkfjasldkfj HTTP/1.0
>and either gets a 404 if it's wrong, or a 200 if it's correct.
As suggested already in early drafts of the YP Protocol, there should be a proper way to check if a stream is still reachable and running (and even maybe fetch updated metadata while at it).
This could be solved by implementing HTTP 1.1 HEAD and setting some headers, or as the TODO suggest, making a dedicated endpoint for it.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2108Registrable URL handlers in connection.c instead of hardcoded list2018-07-16T09:09:26ZMarvin ScholzRegistrable URL handlers in connection.c instead of hardcoded listSuggested in TODO
>general registerable url-handlers in connection.c rather than hard-coded list
>(already getting unmaintainable)Suggested in TODO
>general registerable url-handlers in connection.c rather than hard-coded list
>(already getting unmaintainable)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2109Abstract admin functionality to set of commands and handlers2020-10-15T09:20:39ZMarvin ScholzAbstract admin functionality to set of commands and handlers>abstract all admin functionality to a set of commands, and command handlers.
>
>Make /admin/* just parse according to a set of rules, and dispatch generic
>commands through that.
>
>Use this for alternative admin interfaces (GUI? telnet...>abstract all admin functionality to a set of commands, and command handlers.
>
>Make /admin/* just parse according to a set of rules, and dispatch generic
>commands through that.
>
>Use this for alternative admin interfaces (GUI? telnet interface?)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2110Timer-based functionalities should use single timer thread2022-05-16T23:03:32ZMarvin ScholzTimer-based functionalities should use single timer thread>all timer-based functionality (yp updates, slave/relay checks) should have a
>single timer thread which dispatches events through the normal event
>mechanism (to worker threads from the main pool). This will reduce the
>extraneous threa...>all timer-based functionality (yp updates, slave/relay checks) should have a
>single timer thread which dispatches events through the normal event
>mechanism (to worker threads from the main pool). This will reduce the
>extraneous thread count.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2111Race condition in fserv.c?2018-10-04T10:53:27ZMarvin ScholzRace condition in fserv.c?>race condition between avl_tree_unlock(pending_tree) and
>thread_cond_wait(&fserv_cond) in fserv.c, it's a pain to fix but should be.
Found in the TODO, still relevant?>race condition between avl_tree_unlock(pending_tree) and
>thread_cond_wait(&fserv_cond) in fserv.c, it's a pain to fix but should be.
Found in the TODO, still relevant?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2112Locks on avl client_trees needed?2020-10-11T11:18:30ZMarvin ScholzLocks on avl client_trees needed?>do we need to use locks on the avl client_trees in source.c and fserv.c?
Found in TODO, still relevant?>do we need to use locks on the avl client_trees in source.c and fserv.c?
Found in TODO, still relevant?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2116Write FAQ on how to set <hostname> correctly2022-03-21T09:35:20ZPhilipp SchafftWrite FAQ on how to set <hostname> correctlyAs we introduced checks for <hostname> and may going to be more strict with this over time documentation needs to be updated.
- Check if documentation tells about setting this to an IP address anywhere. If so correct this.
- Write a sma...As we introduced checks for <hostname> and may going to be more strict with this over time documentation needs to be updated.
- Check if documentation tells about setting this to an IP address anywhere. If so correct this.
- Write a small FAQ on setting <hostname> correctly. This should be mostly for those who aren't familiar with the concept of hostnames.
Some ideas for the FAQ:
- Tell what a hostname, a FQDN is and how it is related and more importantly not related to IP addresses.
- Include a hint to use same domain as webpage.
- Include hint for falling back to whatever server hoster use a default hostname.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2117Creating a policy for removing support for obsoleted features/interfaces2018-06-16T22:40:11ZPhilipp SchafftCreating a policy for removing support for obsoleted features/interfacesThere needs to be a policy that tells when and how to remove a feature or interface that has been obsoleted for some reason. This policy will become very important when moving forward. Icecast recently had some major changes that move th...There needs to be a policy that tells when and how to remove a feature or interface that has been obsoleted for some reason. This policy will become very important when moving forward. Icecast recently had some major changes that move the internals away from how 2.3.2 was. Such a policy will help much to avoid keeping workarounds for older ways of doing stuff in the codebase and will be a major improvement to the code quality and maintainability.Icecast 2.5.0Thomas B. RückerThomas B. Rücker