Icecast-libshout issueshttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues2023-08-15T10:34:09Zhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2340reserved identifier violation2023-08-15T10:34:09ZMarkus Elfringreserved identifier violation:eyes: I would like to point out that an identifier like “[`__LIBSHOUT_SHOUT_H__`](https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/d8592a0be35867691219f470b7db506fbb8cb912/include/shout/shout.h.in#L22 "Update candidate")” [does not ...:eyes: I would like to point out that an identifier like “[`__LIBSHOUT_SHOUT_H__`](https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/d8592a0be35867691219f470b7db506fbb8cb912/include/shout/shout.h.in#L22 "Update candidate")” [does not fit](https://wiki.sei.cmu.edu/confluence/display/cplusplus/DCL51-CPP.+Do+not+declare+or+define+a+reserved+identifier#DCL51CPP.Donotdeclareordefineareservedidentifier-NoncompliantCodeExample%28HeaderGuard%29 "Do not declare an identifier which is reserved for the compiler implementation.") to the expected naming convention of the C++ language standard.
:thought_balloon: Would you like to adjust your selection for unique names?https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2311Add support for JWT tokens2023-03-18T10:25:44ZThiago SantosAdd support for JWT tokensAdds support for setting a JWT authorization token (or any opaque token) to libshout. It will be used as an "Authorization: Bearer <token>" header instead of the usual user/password header for HTTP requests.Adds support for setting a JWT authorization token (or any opaque token) to libshout. It will be used as an "Authorization: Bearer <token>" header instead of the usual user/password header for HTTP requests.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2322Impossible install2023-03-10T12:59:04ZTitouan PetitImpossible install`npm install --save nodeshout` on Raspbian :
Log : https://hastebin.com/esevepetal.rb`npm install --save nodeshout` on Raspbian :
Log : https://hastebin.com/esevepetal.rbhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2323Build on Windows / CMake2023-03-09T10:24:28ZJan HolthuisBuild on Windows / CMakeI'm unable to find documentation regarding building on Windows.
Would you be interested in a CMake build file?I'm unable to find documentation regarding building on Windows.
Would you be interested in a CMake build file?https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2339Remove getters2023-03-09T10:19:51ZPhilipp SchafftRemove gettersCurrently libshout provides a number of getters for several settings. It seems unclear to me what they are useful for. Therefore I suggest to deprecate them and remove them with the next ABI change.
List of relevant getters:
* `shout_ge...Currently libshout provides a number of getters for several settings. It seems unclear to me what they are useful for. Therefore I suggest to deprecate them and remove them with the next ABI change.
List of relevant getters:
* `shout_get_host()`
* `shout_get_port()`
* `shout_get_agent()`
* `shout_get_tls()` There is/was/might be confusion on whether this returns the configuration or the current value.
* `shout_get_ca_directory()`
* `shout_get_ca_file()`
* `shout_get_allowed_ciphers()` The value is not supposed to be set by the API user. Therefore a getter may be still be good (e.g. for status display).
* `shout_get_user()`
* `shout_get_password()` Via #2338
* `shout_get_client_certificate()`
* `shout_get_mount()`
* `shout_get_audio_info()`
* `shout_get_meta()`
* `shout_get_public()`
* `shout_get_content_language()`
* `shout_get_content_format()`
* `shout_get_protocol()` There is/was/might be confusion on whether this returns the configuration or the current value.
* `shout_get_nonblocking()` The returned value is a `SHOUT_BLOCKING_xxx` constant. There had been confusion on this before.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2338Removal of shout_get_password()2023-03-09T10:13:57ZPhilipp SchafftRemoval of shout_get_password()Currently libshout allows the retrieval of the user password via `shout_get_password()`. To me it seems like this is a very strange usecase. Specifically with a security relevant information like the user's password. Therefore I suggest ...Currently libshout allows the retrieval of the user password via `shout_get_password()`. To me it seems like this is a very strange usecase. Specifically with a security relevant information like the user's password. Therefore I suggest to deprecate this function and remove it with the next ABI change.
Notes:
* Removal of the function will clean up the code slightly.
* The information is still within the process' memory. This does not improve security against attacks. The main intention of this ticket is to hint developers into not using bad patterns.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2327When preventing caller "abuse-after-free", abort()2023-03-09T09:48:58ZMoritz GrimmWhen preventing caller "abuse-after-free", abort()The shout_free() function attempts to prevent use-after-free issues by not doing anything in case the caller still has an open connection. While this can mitigate security issues in calling applications, it covers up these flaws in the f...The shout_free() function attempts to prevent use-after-free issues by not doing anything in case the caller still has an open connection. While this can mitigate security issues in calling applications, it covers up these flaws in the form of hard to detect memory leaks.
Libshout should either leave the responsibility for these kinds of defects where they belong and not perform the "is a connection still open?" check, as it will never be able to solve _all_ of these problems (and applications running into this _will_ have other problems as well and are in some dire need of SAST tools).
However, since there is some merit to this safeguard, at least make it highly visible with a proper, noisy abort(): [shout_free_abort_before_use-after-free.diff](/uploads/7eb49ff1ce810e41d523e54cbb6f8428/shout_free_abort_before_use-after-free.diff) -- it might be a wake-up call!https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2337TLS connections not shutting down correctly (blocking mode)2023-02-19T15:44:55ZMoritz GrimmTLS connections not shutting down correctly (blocking mode)shout_tls_close() does not check the return value of SSL_shutdown() to complete a bidirectional shutdown. As a result the TLS connection to Icecast remains open when using libshout in blocking mode. As a result, ezstream users are unable...shout_tls_close() does not check the return value of SSL_shutdown() to complete a bidirectional shutdown. As a result the TLS connection to Icecast remains open when using libshout in blocking mode. As a result, ezstream users are unable to terminate and restart their streams (Icecast prevents multiple source connections to the same mountpoint). See https://gitlab.xiph.org/xiph/ezstream/-/issues/2269 for reference.
A naive patch that solves the issue is attached as [SSL_shutdown.diff](/uploads/0b95fd60e6b3293400fbf3344e7988b8/SSL_shutdown.diff), but that won't work in non-blocking mode ...https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2336a potential NPD in source file src/proto_http.c2022-09-13T10:40:11Zash1852a potential NPD in source file src/proto_http.cHi, I found a potential null pointer dereference bug in the project source code of libshout, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that gen...Hi, I found a potential null pointer dereference bug in the project source code of libshout, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the file path can be seen in the blue framed section.
![getvar](/uploads/d440a52b893294bb5844c94ffe3e2a93/getvar.jpg)
Although the code shown is for the latest but is still exist in current version.
What I'm confused about is, some empty judgment operation to return value of httpp_getvar can be found in some code snippets of the libshout project, so I'm not sure if the context of this snippet can assert that the call-statement won't return null, if so please give me some hints.thank you for checking if this bug is true.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2335Segfault when public is "True"2022-05-03T10:46:51ZAlexey ParamonovSegfault when public is "True"[icecast_3.conf](/uploads/d60903ca7906dc7a0087674798fdb63c/icecast_3.conf)
Icecast 2.5 (Icecast 2.4.99.3) dies with a segfault if there are the following lines in the config file:
```
<public>1</public>
<stream-name>Click ...[icecast_3.conf](/uploads/d60903ca7906dc7a0087674798fdb63c/icecast_3.conf)
Icecast 2.5 (Icecast 2.4.99.3) dies with a segfault if there are the following lines in the config file:
```
<public>1</public>
<stream-name>Click Your Radio Dutch</stream-name>
<stream-description>The best in Dutch Music and Comedy</stream-description>
<stream-url>www.clickyourradio.com</stream-url>
<genre>Music &amp; Comedy</genre>
```
Complete config file is attachedhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2334Mixxx build patches2022-04-12T11:07:10ZDaniel SchürmannMixxx build patchesThis is the set of patches we apply in the Mixxx project to build libshout on Linux/Windows/MacOs.
[0006-Handle-unhandled-enum-values-in-switch-statements.patch](/uploads/697b5afa3df8c0a07efd437d36b2776b/0006-Handle-unhandled-enum-valu...This is the set of patches we apply in the Mixxx project to build libshout on Linux/Windows/MacOs.
[0006-Handle-unhandled-enum-values-in-switch-statements.patch](/uploads/697b5afa3df8c0a07efd437d36b2776b/0006-Handle-unhandled-enum-values-in-switch-statements.patch)
[0005-Verify-port-number-length.patch](/uploads/89e9c67e61740c4965d9141407c14c2c/0005-Verify-port-number-length.patch)
[0004-Fix-includes.patch](/uploads/716c9fa35c186257ef1431fb87ca865d/0004-Fix-includes.patch)
[0003-replace-illegal-void-arythmetric.patch](/uploads/f6f23b2338e477af3aa5d0c43372063b/0003-replace-illegal-void-arythmetric.patch)
[0002-fix-os.h.patch](/uploads/34c49851823f285aaeae15b3decca10b/0002-fix-os.h.patch)
[0001-Remove-unsused-strings.h.patch](/uploads/519033c12062e1d0a4cd010254840e73/0001-Remove-unsused-strings.h.patch)https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2316Cannot connect to server in nonblocking mode ("Please retry current operation.")2022-04-12T11:02:45ZTomasz LemiechCannot connect to server in nonblocking mode ("Please retry current operation.")After reenabling nonblocking sockets by applying the fix (workaround?) described in https://gitlab.xiph.org/xiph/icecast-libshout/issues/2315 the client is unable to connect to the server at all. HTTP request is sent, but the client clos...After reenabling nonblocking sockets by applying the fix (workaround?) described in https://gitlab.xiph.org/xiph/icecast-libshout/issues/2315 the client is unable to connect to the server at all. HTTP request is sent, but the client closes the connection before the reply arrives.
```
$ ./nonblocking
Error connecting: Please retry current operation.
```
strace shows the following:
```
$ strace -e connect,fcntl,fcntl64,select ./nonblocking
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(5, [4], [4], [4], {tv_sec=0, tv_usec=1000}) = 1 (out [4], left {tv_sec=0, tv_usec=999})
select(5, NULL, [4], NULL, {tv_sec=0, tv_usec=0}) = 1 (out [4], left {tv_sec=0, tv_usec=0})
select(5, [4], NULL, [4], {tv_sec=0, tv_usec=1000}) = 0 (Timeout)
Error connecting: Please retry current operation.
+++ exited with 0 +++
```
The third `select` call times out. Backtrace at this `select` call:
```
#0 __GI___select (nfds=5, readfds=readfds@entry=0x7fffffffc6c0, writefds=writefds@entry=0x0,
exceptfds=exceptfds@entry=0x7fffffffc7c0, timeout=timeout@entry=0x7fffffffc6b0) at ../sysdeps/unix/sysv/linux/select.c:39
#1 0x00007ffff7f78f3e in shout_connection_iter__wait_for_io (con=con@entry=0x55555555aa10, for_write=for_write@entry=0,
timeout=timeout@entry=0, shout=0x55555555a490, for_read=1) at connection.c:144
#2 0x00007ffff7f7961c in shout_connection_iter__message (shout=0x55555555a490, con=0x55555555aa10) at connection.c:374
#3 shout_connection_iter (shout=<optimized out>, con=<optimized out>) at connection.c:478
#4 shout_connection_iter (con=con@entry=0x55555555aa10, shout=shout@entry=0x55555555a490) at connection.c:442
#5 0x00007ffff7f77571 in try_connect (self=self@entry=0x55555555a490) at shout.c:1333
#6 0x00007ffff7f77752 in shout_open (self=0x55555555a490) at shout.c:189
#7 0x000055555555529b in main () at nonblocking.c:66
```
As a result of this timeout, `shout_connection_iter__wait_for_io` returns `SHOUT_RS_TIMEOUT` to `shout_connection_iter__message`, which then gets propagated back to `shout_connection_iter`. Now due to the following condition in `__iter` macro:
```C
case SHOUT_RS_TIMEOUT: \
case SHOUT_RS_NOTNOW: \
if (con->nonblocking == SHOUT_BLOCKING_NONE) \
return SHOUTERR_RETRY; \
retry = 1; \
```
`SHOUTERR_RETRY` is returned from `shout_connection_iter` and propagated back via `try_connect` and `shout_open` to the caller, which is usually not prepared to handle this value (it expects `SHOUTERR_SUCCESS`, `SHOUTERR_CONNECTED` or `SHOUTERR_BUSY`).
A one-line fix to the above:
```C
if (con->nonblocking == SHOUT_BLOCKING_NONE) \
return SHOUTERR_BUSY; \
```
fixes the problem.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2325No connection in nonblocking mode, retry shout_open() fails.2022-04-12T11:02:27ZDaniel SchürmannNo connection in nonblocking mode, retry shout_open() fails.Probably since 2.4.2 and https://gitlab.xiph.org/xiph/icecast-libshout/-/commit/032aa10d93553ede0bbfb1c2f094f9794f12da15
shout_open() returns SHOUTERR_RETRY instead retry until timeout in
https://gitlab.xiph.org/xiph/icecast-libshout/-/...Probably since 2.4.2 and https://gitlab.xiph.org/xiph/icecast-libshout/-/commit/032aa10d93553ede0bbfb1c2f094f9794f12da15
shout_open() returns SHOUTERR_RETRY instead retry until timeout in
https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/master/src/connection.c#L464
Unfortunately it is not possible without closing shout to continue the iteration using shout_open().
It fails with SHOUTERR_CONNECTED
https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/master/src/shout.c#L185
Calling shout_close() does not fix the issue, because it starts the iteration from the beginning.
Is there another public function that can be called?
In my test 70 loops are required to open the connection.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2328libshout 2.4.5 mp3 song metadata not updating2022-04-12T11:02:02ZStephen Fairchildlibshout 2.4.5 mp3 song metadata not updatingCalls to shout_set_metadata() are not updating the song metadata on the connected Icecast server when libshout 2.4.5 is streaming in mp3 format. My testing indicates the issue is not present in libshout version 2.4.4.
[libshout_mp3_met...Calls to shout_set_metadata() are not updating the song metadata on the connected Icecast server when libshout 2.4.5 is streaming in mp3 format. My testing indicates the issue is not present in libshout version 2.4.4.
[libshout_mp3_metadata.c](/uploads/d163d9fcbb3757b333b1ac2bb5d999e6/libshout_mp3_metadata.c)https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2331Add an option to disable tools2022-04-10T17:32:00ZFabrice FontaineAdd an option to disable toolsAs I'm unable to fork the project, please find attached a patch that allow the user to disable tools.
[0001-configure.ac-add-an-option-to-disable-tools.patch](/uploads/853966c2c49c76d002f218578e68c1a5/0001-configure.ac-add-an-option-to-...As I'm unable to fork the project, please find attached a patch that allow the user to disable tools.
[0001-configure.ac-add-an-option-to-disable-tools.patch](/uploads/853966c2c49c76d002f218578e68c1a5/0001-configure.ac-add-an-option-to-disable-tools.patch)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2330URL-escaping ?=& in the mountpoint prevents mountpoints with query strings2022-04-09T19:27:00ZNiko DittmannURL-escaping ?=& in the mountpoint prevents mountpoints with query strings#11b83da8 breaks connecting to mountpoints with a query string.
We are running a libshout compatible streaming server (at least we try ;) ) which uses a query string parameter to set a priority for a source client. This way a newly conn...#11b83da8 breaks connecting to mountpoints with a query string.
We are running a libshout compatible streaming server (at least we try ;) ) which uses a query string parameter to set a priority for a source client. This way a newly connecting source client can auto-kick an existing source client by providing a higher priority. I only now realized that by updating from my old libshout 2.3.1 on debian to 2.4.3 on ubuntu query string get now escaped:
```
SOURCE /m1?prio=3 HTTP/1.0 "ices/0.4 libshout/2.3.1"
SOURCE /m1%3fprio%3d3 HTTP/1.0 "ices/0.4 libshout/2.4.3"
```
I realize that the exact semantics of "mountpoints" aren't formaly specified (or are they?) but this completely broke my expectation of a mount point basically just being the path of a URL.
I opened an [issue on github](https://github.com/xiph/Icecast-libshout/issues/22) before I found the repo here. I'm gonna close over there and refer to this issue here.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/23242.4.5 not tagged2022-04-09T19:22:43ZBe Ing2.4.5 not taggedSource code for version 2.4.5 is available to download at http://downloads.xiph.org/releases/libshout and the release is listed in https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/master/NEWS#L1 but there is no Git tag.Source code for version 2.4.5 is available to download at http://downloads.xiph.org/releases/libshout and the release is listed in https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/master/NEWS#L1 but there is no Git tag.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2333Support 30X Redirects2021-11-18T14:26:16ZJamie WoodsSupport 30X RedirectsIt would be very useful for libshout to natively handle receiving 301/302 redirects, when connecting as a source.
This would allow various streaming applications to connect to a different Icecast instance dynamically (for example - regi...It would be very useful for libshout to natively handle receiving 301/302 redirects, when connecting as a source.
This would allow various streaming applications to connect to a different Icecast instance dynamically (for example - regional clusters of servers)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2332Patch for macOS >= 11.x2021-10-26T13:06:10ZMichka PopoffPatch for macOS >= 11.xHi
Here is a patch we are using in Homebrew (the package manager for macOS and Linux) to build libshout.
The current build is broken and causes the library to be linked with a flat
namespace, which might cause issues when dynamically lo...Hi
Here is a patch we are using in Homebrew (the package manager for macOS and Linux) to build libshout.
The current build is broken and causes the library to be linked with a flat
namespace, which might cause issues when dynamically loading the library with
dlopen under some modes:
```
diff -u libshout-2.4.5-old/configure libshout-2.4.5/configure
--- libshout-2.4.5-old/configure 2021-10-21 12:28:29.000000000 +0200
+++ libshout-2.4.5/configure 2021-10-21 12:31:31.000000000 +0200
@@ -7582,17 +7582,12 @@
_lt_dar_allow_undefined='${wl}-undefined ${wl}suppress' ;;
darwin1.*)
_lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
- darwin*) # darwin 5.x on
- # if running on 10.5 or later, the deployment target defaults
- # to the OS version, if on x86, and 10.4, the deployment
- # target defaults to 10.4. Don't you love it?
- case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
- 10.0,*86*-darwin8*|10.0,*-darwin[91]*)
- _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
- 10.[012]*)
- _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
- 10.*)
- _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
+ darwin*)
+ case ${MACOSX_DEPLOYMENT_TARGET},$host in
+ 10.[[012]],*|,*powerpc*)
+ _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
+ *)
+ _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
esac
;;
esac
```
This is a patch for the configure file, but it should be applied to the the libtool.m4 file. I am not an expert on how you have setup the m4 folder in your project, so I'll let you handle the addition of that patch.
For reference:
https://github.com/Homebrew/homebrew-core/pull/87694Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2329Unbreak shout.pc (on non-GNU systems)2021-04-16T12:46:56ZMoritz GrimmUnbreak shout.pc (on non-GNU systems)The pkgconfig file shout.pc contains a list of requirements starting with an empty value:
`Requires.private: , ogg, vorbis, theora, speex, libssl`
This is not well-formed and doesn't work with pkgconfig on OpenBSD (for example). Since ...The pkgconfig file shout.pc contains a list of requirements starting with an empty value:
`Requires.private: , ogg, vorbis, theora, speex, libssl`
This is not well-formed and doesn't work with pkgconfig on OpenBSD (for example). Since libogg is a must-have dependency, the simple fix is to just start the list with it.
Patch: [libshout_proper_shout_pc.diff](/uploads/5cf7acd7e02ea62a9712a79375a6b663/libshout_proper_shout_pc.diff)