Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2023-04-06T12:15:53Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2470Missing documentation for version 'latest'2023-04-06T12:15:53ZJonas L.Missing documentation for version 'latest'Documentation for some versions is missing on the website https://icecast.org/docs/:
- https://icecast.org/docs/icecast-latest
- https://icecast.org/docs/icecast-2.4.4Documentation for some versions is missing on the website https://icecast.org/docs/:
- https://icecast.org/docs/icecast-latest
- https://icecast.org/docs/icecast-2.4.4Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2468lost TCP connections of relays are not handled gracefully2023-04-06T22:19:52ZBjoern Jackelost TCP connections of relays are not handled gracefullyI'm running icecast with a mointpoint that has both a IPv4 and a IPv6 address. IPv4 and IPv6 traffic go over different providers, so this is also being done for redundancy reasons.
I tested how well icecast handles the fallback from the...I'm running icecast with a mointpoint that has both a IPv4 and a IPv6 address. IPv4 and IPv6 traffic go over different providers, so this is also being done for redundancy reasons.
I tested how well icecast handles the fallback from the IPv4 path to the IPv6 path or vice versa by killing the TCP connection or changing the route to "unreachable". It turns out that icecast connects to the other IPv4 or IPv6 path but connected clients will lose their connection immediately, which is bad. Of course we don't want to lose all our users and hope for them to reconnect to our stream in case of such a fallback in our upstream mount.
I tested exactly the same szenario with https://rocketbroadcaster.com/streaming-audio-server - and the Rocket Streaming Audio Server *does* handle this gracefully. The only thing that I was able to notice from the client side here was an ffmped audio decoding error message when the RSAS switched from the one path to the other path. But the switch was almost not noticable by clients.
It would be great if icecast would handle such a case as gracefully as the Rocket Streaming Audio Server.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2465Add support for RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token...2023-03-18T10:25:42ZPhilipp SchafftAdd support for RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token UsageSupport for RFC 6750 should be added. In a first iteration this only needs to be supported by the `url` and the `enforce-auth` backend.
See also: xiph/icecast-libshout#2311Support for RFC 6750 should be added. In a first iteration this only needs to be supported by the `url` and the `enforce-auth` backend.
See also: xiph/icecast-libshout#2311Philipp SchafftPhilipp Schaffthttps://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-server/-/issues/2461Converting URL auth to use string renderer.2023-02-27T11:48:36ZPhilipp SchafftConverting URL auth to use string renderer.Currently the URL auth backend builds it's POST data itself. This should be migrated to use string renderer. The code from URL events can be used as a template.Currently the URL auth backend builds it's POST data itself. This should be migrated to use string renderer. The code from URL events can be used as a template.Philipp SchafftPhilipp Schaffthttps://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-libigloo/-/issues/7./configure CFLAGS='-flto -O2' triggers lto-type-mismatch warnings between sr...2023-02-06T11:29:48ZPetr Pisar./configure CFLAGS='-flto -O2' triggers lto-type-mismatch warnings between src/igloo.c and src/ro.cWhen building with gcc-13.0.1 and link-time optimization is enabled (-flto), the compiler warns about mismatching function prototypes among compilation units:
~~~~
/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -flto=auto -ffat-lto-...When building with gcc-13.0.1 and link-time optimization is enabled (-flto), the compiler warns about mismatching function prototypes among compilation units:
~~~~
/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=z13 -mtune=z14 -fasynchronous-unwind-tables -fstack-clash-protection -Wextra -pthread -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -o libigloo.la -rpath /usr/lib64 src/igloo.lo src/error.lo src/rwlock.lo src/time.lo src/feature.lo src/list.lo src/digest.lo src/prng.lo src/cs.lo src/sp.lo src/ro.lo src/tap.lo src/uuid.lo -lm -lrhash -lpthread
libtool: link: gcc -shared -fPIC -DPIC src/.libs/igloo.o src/.libs/error.o src/.libs/rwlock.o src/.libs/time.o src/.libs/feature.o src/.libs/list.o src/.libs/digest.o src/.libs/prng.o src/.libs/cs.o src/.libs/sp.o src/.libs/ro.o src/.libs/tap.o src/.libs/uuid.o -lm -lrhash -lpthread -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -flto=auto -g -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=z13 -mtune=z14 -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -pthread -Wl,-soname -Wl,libigloo.so.0 -o .libs/libigloo.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libigloo.so.0" && ln -s "libigloo.so.0.0.0" "libigloo.so.0")
libtool: link: (cd ".libs" && rm -f "libigloo.so" && ln -s "libigloo.so.0.0.0" "libigloo.so")
libtool: link: ( cd ".libs" && rm -f "libigloo.la" && ln -s "../libigloo.la" "libigloo.la" )
make[1]: Leaving directory '/builddir/build/BUILD/libigloo-0.9.2'
./include/igloo/ro.h:178:17: warning: type of 'igloo_ro_ref_raw' does not match original declaration [-Wlto-type-mismatch]
178 | igloo_error_t igloo_ro_ref_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type);
| ^
src/ro.c:446:17: note: type mismatch in parameter 1
446 | igloo_error_t igloo_ro_ref_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type)
| ^
src/ro.c:446:17: note: 'igloo_ro_ref_raw' was previously declared here
src/ro.c:446:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
./include/igloo/ro.h:183:17: warning: type of 'igloo_ro_weak_ref_replace_raw' does not match original declaration [-Wlto-type-mismatch]
183 | igloo_error_t igloo_ro_weak_ref_replace_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type);
| ^
src/ro.c:658:17: note: type mismatch in parameter 1
658 | igloo_error_t igloo_ro_weak_ref_replace_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type)
| ^
src/ro.c:658:17: note: 'igloo_ro_weak_ref_replace_raw' was previously declared here
src/ro.c:658:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
src/private.h:72:12: warning: type of 'igloo_ro_get_instance_unsafe' does not match original declaration [-Wlto-type-mismatch]
72 | igloo_ro_t igloo_ro_get_instance_unsafe(igloo_ro_t self, const igloo_ro_type_t *type);
| ^
src/ro.c:974:12: note: return value type mismatch
974 | igloo_ro_t igloo_ro_get_instance_unsafe(igloo_ro_t self, const igloo_ro_type_t *type)
| ^
src/ro.c:974:12: note: 'igloo_ro_get_instance_unsafe' was previously declared here
src/ro.c:974:12: note: code may be misoptimized unless '-fno-strict-aliasing' is used
./include/igloo/ro.h:189:17: warning: type of 'igloo_ro_stringify_raw' does not match original declaration [-Wlto-type-mismatch]
189 | igloo_error_t igloo_ro_stringify_raw(igloo_ro_t self, char **result, igloo_ro_sy_t flags, const igloo_ro_type_t *type);
| ^
src/ro.c:757:17: note: type mismatch in parameter 1
757 | igloo_error_t igloo_ro_stringify_raw(igloo_ro_t self, char **result, igloo_ro_sy_t flags, const igloo_ro_type_t *type)
| ^
src/ro.c:757:17: note: 'igloo_ro_stringify_raw' was previously declared here
src/ro.c:757:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
./include/igloo/ro.h:175:12: warning: type of 'igloo_RO_TO_TYPE_raw' does not match original declaration [-Wlto-type-mismatch]
175 | igloo_ro_t igloo_RO_TO_TYPE_raw(igloo_ro_t object, const igloo_ro_type_t *type) igloo_ATTR_F_HOT;
| ^
src/ro.c:250:17: note: return value type mismatch
250 | igloo_ro_t igloo_RO_TO_TYPE_raw(igloo_ro_t object, const igloo_ro_type_t *type)
| ^
src/ro.c:250:17: note: 'igloo_RO_TO_TYPE_raw' was previously declared here
src/ro.c:250:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
src/private.h:74:21: warning: type of 'igloo_instance_get_prng_state' does not match original declaration [-Wlto-type-mismatch]
74 | igloo_prng_state_t *igloo_instance_get_prng_state(igloo_ro_t self, size_t *instancelen);
| ^
src/igloo.c:314:21: note: type mismatch in parameter 1
314 | igloo_prng_state_t *igloo_instance_get_prng_state(igloo_ro_t self, size_t *instancelen)
| ^
src/igloo.c:314:21: note: 'igloo_instance_get_prng_state' was previously declared here
src/igloo.c:314:21: note: code may be misoptimized unless '-fno-strict-aliasing' is used
src/private.h:73:19: warning: type of 'igloo_instance_get_stringpool_state' does not match original declaration [-Wlto-type-mismatch]
73 | igloo_sp_state_t *igloo_instance_get_stringpool_state(igloo_ro_t self);
| ^
src/igloo.c:304:19: note: type mismatch in parameter 1
304 | igloo_sp_state_t *igloo_instance_get_stringpool_state(igloo_ro_t self)
| ^
src/igloo.c:304:19: note: 'igloo_instance_get_stringpool_state' was previously declared here
src/igloo.c:304:19: note: code may be misoptimized unless '-fno-strict-aliasing' is used
~~~~
While the printed lines are character by character equal, it is probably igloo_ro_t type which differ: include/igloo/types.h defines it as a union of igloo_RO_TYPE()s or as "void *" depending on igloo_ATTR_T_TRANSPARENT_UNION macro. Further, an union member "igloo_RO_TYPE(igloo_ro_stub_t)" expands to "subtype__igloo_ro_stub_t *". Hence different types. src/igloo.c and src/ro.c probably differ in a list of included header files. I agree that the GCC warning is not much helpful. The warning can be triggered with "./configure CFLAGS='-flto -O2'" command.
Problem is that GCC since -O2 optimization level assumes that pointers to different types cannot alias to the same memory and optimizes the code so. This can lead to undefined run-time execution. A brief introduction to strict aliasing can be found at <https://www.geeksforgeeks.org/strict-aliasing-rule-in-c-with-examples/>.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/5Obselete Autoconf macros2023-02-05T13:39:25ZPetr PisarObselete Autoconf macrosWhen regenerating configure script with autoconf-2.71, I can see these warnings:
~~~~
configure.ac:71: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:71: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER...When regenerating configure script with autoconf-2.71, I can see these warnings:
~~~~
configure.ac:71: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:71: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:71: the top level
configure.ac:72: warning: The macro `AC_HEADER_TIME' is obsolete.
configure.ac:72: You should run autoupdate.
./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from...
configure.ac:72: the top level
configure.ac:118: warning: The macro `ACX_PTHREAD' is obsolete.
configure.ac:118: You should run autoupdate.
aclocal.m4:266: ACX_PTHREAD is expanded from...
configure.ac:118: the top level
~~~~~
From Autoconf documentation:
~~~~
-- Macro: AC_HEADER_STDC
This macro is obsolescent. Its sole effect is to make sure that
all the headers that are included by ‘AC_INCLUDES_DEFAULT’ (*note
Default Includes::), but not part of ISO C90, have been checked
for.
All hosted environments that are still of interest for portable
code provide all of the headers specified in ISO C90 (as amended in
1995).
-- Macro: AC_HEADER_TIME
This macro used to check whether it was possible to include
‘time.h’ and ‘sys/time.h’ in the same source file, defining
‘TIME_WITH_SYS_TIME’ if so.
Nowadays, it is equivalent to ‘AC_CHECK_HEADERS([sys/time.h])’,
although it does still define ‘TIME_WITH_SYS_TIME’ for
compatibility’s sake. ‘time.h’ is universally present, and the
systems on which ‘sys/time.h’ conflicted with ‘time.h’ are
obsolete.
~~~~
ACX_PTHREAD was renamed to AX_PTHREAD as can be found in ax_pthread.m4 of autoconf-archive-2022.09.03.Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/4Outdated FSF address2023-02-01T10:58:38ZPetr PisarOutdated FSF addressCOPYING file quotes a postal address of Free Software Foundation. That address is not valid anymore. Current one can be found at <https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt>. Please updates the license wording to provide an u...COPYING file quotes a postal address of Free Software Foundation. That address is not valid anymore. Current one can be found at <https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt>. Please updates the license wording to provide an up-to-date address to your users.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2459Missing documentation for the stats method2023-01-28T20:46:12ZJonas L.Missing documentation for the stats methodHi,
I am unsure if the custom stats method (`curl -X STATS http://icecast:8000`) is deprecated/maintained and if I should use it?
If this can be used in new project, I am looking for some documentation about it. Is there a place where t...Hi,
I am unsure if the custom stats method (`curl -X STATS http://icecast:8000`) is deprecated/maintained and if I should use it?
If this can be used in new project, I am looking for some documentation about it. Is there a place where this already exists?
Thankshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2458IPv6 support?2023-01-03T15:46:45ZFabien SchenkelsIPv6 support?Hi,
It seems that Icecast does not work in IPv6?
I can't bind an IPv6 address, I get this error: `EROR connection/connection.c Could not create listener socket on port 8000 bind 2a0a:xxx`
```
<listen-socket>
<port>8000</port>
<bind...Hi,
It seems that Icecast does not work in IPv6?
I can't bind an IPv6 address, I get this error: `EROR connection/connection.c Could not create listener socket on port 8000 bind 2a0a:xxx`
```
<listen-socket>
<port>8000</port>
<bind-address>2a0a:xxxxx</bind-address>
</listen-socket>
```
thanks for your feedbackMarvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/opus-website/-/issues/1Broken link from FAQ to bug tracker (Trac)2022-12-23T03:37:51ZPhilippe CloutierBroken link from FAQ to bug tracker (Trac)[The _How do I report a bug?_ section of the _OpusFAQ_ wiki page](https://wiki.xiph.org/OpusFAQ#How_do_I_report_a_bug.3F) contains a "file a bug report" link pointing to https://trac.xiph.org/newticket?component=Opus which unfortunately ...[The _How do I report a bug?_ section of the _OpusFAQ_ wiki page](https://wiki.xiph.org/OpusFAQ#How_do_I_report_a_bug.3F) contains a "file a bug report" link pointing to https://trac.xiph.org/newticket?component=Opus which unfortunately appears broken. The error I get trying to access to access that page suggests the trac.xiph.org domain does not exist.https://gitlab.xiph.org/xiph/icecast-ices/-/issues/2325Git tag missing for 2.0.3 release2022-11-21T10:47:44ZtvogelGit tag missing for 2.0.3 releaseHi! It seems, there is no git tag for the 2.0.3 release, yet. Comparing the tar.bz2 contents, I think
git tag v2.0.3 58d89b5d135e07826f5777c6bf62645061dbae5c
should be the correct one. Would you mind to add that?Hi! It seems, there is no git tag for the 2.0.3 release, yet. Comparing the tar.bz2 contents, I think
git tag v2.0.3 58d89b5d135e07826f5777c6bf62645061dbae5c
should be the correct one. Would you mind to add that?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/opus/-/issues/2361Building libopus for mac os x universal binary2022-09-17T17:20:30Zcbarrett69Building libopus for mac os x universal binaryCurrently, the active mac hardware includes both x86_64 and arm64 architecture. Apple supports universal binaries that include support for both of these architectures, such that the appropriate code is used at runtime. In order for an ...Currently, the active mac hardware includes both x86_64 and arm64 architecture. Apple supports universal binaries that include support for both of these architectures, such that the appropriate code is used at runtime. In order for an application to successfully support both, all dependent libraries must also be universal binaries. Libopus is a dependent library for my application.
My build machine is x86_64, but Apple includes the compilers for both architectures in recent versions of Xcode.
For most libs (libogg, libflac, ...) the following seems to work, but it does not work for libopus:
```
./configure CXXFLAGS="-arch x86_64 -arch arm64" CFLAGS="-arch x86_64 -arch arm64"
make -j8
sudo make install
```
result:
checking How to get X86 CPU Info... configure: error: no supported Get CPU Info method, please disable run-time CPU capabilities detection or intrinsics
Then I tried:
```
./configure --disable-rtcd CXXFLAGS="-arch x86_64 -arch arm64" CFLAGS="-arch x86_64 -arch arm64"
make -j8
```
result:
Undefined symbols for architecture arm64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2451a potential bug of NPD2022-09-14T08:41:54Zash1852a potential bug of NPDHi, 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/8fc4ca569f4f83b6f01a8c2ea5e57342/getvar.jpg)
what i am confused about is, there are some code snippets can be found in project that checking if return value of httpp_getvar equal to null, maybe the context in which the code snippet is located can asserts that the return value cannot be equal to null? but I haven't found such code can assert this.
Although the code shown is for the latest but is still exist in current version.would you help to check if this bug is true?thank you for your patience and effort!Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/vorbis/-/issues/2347a potential bug of NPD2022-09-13T10:38:25Zash1852a potential bug of NPDHi, I found a potential null pointer dereference bug in the project source code of vorbis, 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 gener...Hi, I found a potential null pointer dereference bug in the project source code of vorbis, 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 red arrows represent the control flow,the file path can be seen in the blue framed section.
![1662360760592](https://user-images.githubusercontent.com/87304478/188383134-07ef0506-a2c9-4a29-861a-b132c5c0d7f1.jpg)
Although the code shown is for version 1.3.6 but is still exist in current version
would you can help to check if this bug is true?thank you for your effort and patience!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/celt/-/issues/40.11.3: test suite is failing2024-01-22T12:01:11ZTomasz Kłoczko0.11.3: test suite is failing```console
+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check
Making check in libcelt
/usr/bin/make check-TESTS
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/libcelt'
PASS: match-test.sh
make[3]: Leaving directory '/ho...```console
+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check
Making check in libcelt
/usr/bin/make check-TESTS
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/libcelt'
PASS: match-test.sh
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/libcelt'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/libcelt'
============================================================================
Testsuite summary for
============================================================================
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/libcelt'
Making check in tests
/usr/bin/make check-TESTS
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: type-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: laplace-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: mathops-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: dft-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: mdct-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
FAIL: tandem-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: ectest
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: cwrs32-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
============================
: tests/test-suite.log
============================
# TOTAL: 8
# PASS: 7
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: tandem-test
=================
Error: celt_decode returned unknown error
Error: celt_decode returned unknown error
Error: celt_decode returned unknown error
Error: at 30 bytes_per_frame celt_decode returned unknown error
CELT codec tests. Random seed: 3273316686 (0FC4)
Testing asynchronous tandeming (48000Hz, 1ch, 960 samples, 30 - 320 bytes).
FAIL tandem-test (exit status: 1)
============================================================================
Testsuite summary for
============================================================================
# TOTAL: 8
# PASS: 7
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
============================================================================
```
content of the tests/test-suite.log
```console
============================
: tests/test-suite.log
============================
# TOTAL: 8
# PASS: 7
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: tandem-test
=================
Error: celt_decode returned unknown error
Error: celt_decode returned unknown error
Error: celt_decode returned unknown error
Error: at 30 bytes_per_frame celt_decode returned unknown error
CELT codec tests. Random seed: 3273316686 (0FC4)
Testing asynchronous tandeming (48000Hz, 1ch, 960 samples, 30 - 320 bytes).
FAIL tandem-test (exit status: 1)
```https://gitlab.xiph.org/xiph/celt/-/issues/30.11.3: autoreconf warnings2022-08-26T14:30:42ZTomasz Kłoczko0.11.3: autoreconf warningsautoconf 2.71
```
+ cd celt-0.11.3
+ autoreconf -fiv
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autor...autoconf 2.71
```
+ cd celt-0.11.3
+ autoreconf -fiv
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: aclocal --force
autoreconf: running: /usr/bin/autoconf --force
configure.ac:5: warning: 'AM_CONFIG_HEADER': this macro is obsolete.
configure.ac:5: You should use the 'AC_CONFIG_HEADERS' macro instead.
./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:9962: AM_CONFIG_HEADER is expanded from...
configure.ac:5: the top level
configure.ac:29: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated.
./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:9610: AM_INIT_AUTOMAKE is expanded from...
configure.ac:29: the top level
configure.ac:33: warning: The macro `AM_PROG_LIBTOOL' is obsolete.
configure.ac:33: You should run autoupdate.
aclocal.m4:123: AM_PROG_LIBTOOL is expanded from...
configure.ac:33: the top level
configure.ac:35: warning: The macro `AC_PROG_CC_C99' is obsolete.
configure.ac:35: You should run autoupdate.
./lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from...
configure.ac:35: the top level
configure.ac:44: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:44: You should run autoupdate.
./lib/autoconf/general.m4:2847: AC_TRY_COMPILE is expanded from...
configure.ac:44: the top level
configure.ac:56: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:56: You should run autoupdate.
./lib/autoconf/general.m4:2847: AC_TRY_COMPILE is expanded from...
configure.ac:56: the top level
configure.ac:72: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:72: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
aclocal.m4:9094: XIPH_PATH_OGG is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
configure.ac:72: the top level
configure.ac:72: warning: The macro `AC_TRY_RUN' is obsolete.
configure.ac:72: You should run autoupdate.
./lib/autoconf/general.m4:2997: AC_TRY_RUN is expanded from...
aclocal.m4:9094: XIPH_PATH_OGG is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
configure.ac:72: the top level
configure.ac:72: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:72: You should run autoupdate.
./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
aclocal.m4:9094: XIPH_PATH_OGG is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
configure.ac:72: the top level
configure.ac:135: warning: The macro `AC_WARN' is obsolete.
configure.ac:135: You should run autoupdate.
./lib/autoconf/oldnames.m4:33: AC_WARN is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:1534: AC_ARG_ENABLE is expanded from...
configure.ac:135: the top level
configure.ac:158: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
./lib/autoconf/lang.m4:199: AC_LANG_CONFTEST is expanded from...
./lib/autoconf/general.m4:2823: _AC_COMPILE_IFELSE is expanded from...
./lib/autoconf/general.m4:2839: AC_COMPILE_IFELSE is expanded from...
configure.ac:158: the top level
configure.ac:211: warning: AC_OUTPUT should be used without arguments.
configure.ac:211: You should run autoupdate.
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:29: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see:
configure.ac:29: https://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
configure.ac:33: installing './compile'
configure.ac:29: installing './missing'
libcelt/Makefile.am:35: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
libcelt/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
tests/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
tools/Makefile.am:8: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
autoreconf: Leaving directory '.'
```