Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-12-11T08:15:06Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2329(CVE-2017-14633)an out-of-bound array read vul in function mapping0_forward()...2017-12-11T08:15:06ZJiangxin(CVE-2017-14633)an out-of-bound array read vul in function mapping0_forward() in libvorbis 1.3.5```
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples
╰$ gdb encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 ...```
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples
╰$ gdb encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from encoder_example...done.
(gdb) run ../fuzz/crash-oob-read xxx.y4m
Program received signal SIGSEGV, Segmentation fault.
0x00000000005754f9 in mapping0_forward (vb=<optimized out>) at mapping0.c:501
500 if(ci->floor_type[info->floorsubmap[submap]]!=1)return(-1);
(gdb) bt
#0 0x00000000005754f9 in mapping0_forward (vb=<optimized out>) at mapping0.c:500
#1 0x00000000004d3512 in vorbis_analysis (vb=vb@entry=0x7fffffffdbe0, op=op@entry=0x0) at analysis.c:47
#2 0x0000000000410926 in fetch_and_process_audio (audio=0x83b010, audiopage=audiopage@entry=0x7fffffffda40, vo=vo@entry=0x7fffffffde40, vd=vd@entry=0x7fffffffdb50, vb=vb@entry=0x7fffffffdbe0, audioflag=audioflag@entry=0) at encoder_example.c:996
#3 0x0000000000405a9b in main (argc=<optimized out>, argv=<optimized out>) at encoder_example.c:1754
(gdb) i r
rax 0x84b420 8696864
rbx 0x1d3c1a0 30654880
rcx 0x100 256
rdx 0x1e332a0 31666848
rsi 0x1e32e70 31665776
rdi 0x85f000 8777728
rbp 0x7fffffffc850 0x7fffffffc850
rsp 0x7fffffff9ee0 0x7fffffff9ee0
r8 0x1a9b500 27899136
r9 0x8494f0 8688880
r10 0x3e9b02c6 1050346182
r11 0xfe 254
r12 0x1a9b900 27900160
r13 0x84e0e4 8708324
r14 0x84cc00 8702976
r15 0x1b93728 28915496
rip 0x5754f9 0x5754f9 <mapping0_forward+5737>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) x/i $pc
=> 0x5754f9 <mapping0_forward+5737>: cmpl $0x1,0x528(%r9,%r10,4)
(gdb) x/128xb $r9+$r10*4+0x528
0xfaf0a530: Cannot access memory at address 0xfaf0a530
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2328(CVE-2017-14632)call oggpack_writeclear() with uninitialized stack var opb in...2018-05-09T21:59:56ZJiangxin(CVE-2017-14632)call oggpack_writeclear() with uninitialized stack var opb in function vorbis_analysis_headerout() when vi->channels<=0 in libvorbis 1.3.5```
int vorbis_analysis_headerout(vorbis_dsp_state *v,
577 vorbis_comment *vc,
578 ogg_packet *op,
579 ogg_packet *op_comm,
580 ...```
int vorbis_analysis_headerout(vorbis_dsp_state *v,
577 vorbis_comment *vc,
578 ogg_packet *op,
579 ogg_packet *op_comm,
580 ogg_packet *op_code){
581 int ret=OV_EIMPL;
582 vorbis_info *vi=v->vi;
583 oggpack_buffer opb;
584 private_state *b=v->backend_state;
585
586 if(!b||vi->channels<=0){
587 ret=OV_EFAULT;
588 goto err_out;
589 }
...
639 err_out:
640 memset(op,0,sizeof(*op));
641 memset(op_comm,0,sizeof(*op_comm));
642 memset(op_code,0,sizeof(*op_code));
643
644 if(b){
645 oggpack_writeclear(&opb);
646 if(b->header)_ogg_free(b->header);
647 if(b->header1)_ogg_free(b->header1);
648 if(b->header2)_ogg_free(b->header2);
649 b->header=NULL;
650 b->header1=NULL;
651 b->header2=NULL;
652 }
as shown above, if vi->channels<=0 and b!=NULL then func goes to err_out with opb uninitialized, but before calling oggpack_writeclear, it only check if(b),so it will ultimately free a uninitialized memory in oggpack_writeclear:
250 void oggpack_writeclear(oggpack_buffer *b){
251 if(b->buffer)_ogg_free(b->buffer);
252 memset(b,0,sizeof(*b));
253 }
This vul may lead to a DOS or Remote Code Execution in products using libvorbis 1.3.5(latest version).
By the way, I found 8 years ago this function has been found a similar vul :https://bugzilla.mozilla.org/show_bug.cgi?id=550184
while cause of no check of if b=NULL before calling oggpack_writeclear. This time , it is because of incorrect check while no considering if vi->channels<=0.
To reproduce this vul, compile libtheora 1.1.1 libvorbis 1.3.5 libogg 1.3.2 ,then run as below:
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/fuzz
╰$ gdb ../examples/encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../examples/encoder_example...done.
(gdb) run out/Master/crashes/id:000000,sig:06,src:000000,op:flip1,pos:22 xxx.y4m
Starting program: /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example out/Master/crashes/id:000000,sig:06,src:000000,op:flip1,pos:22 xxx.y4m
File out/Master/crashes/id:000000,sig:06,src:000000,op:flip1,pos:22 is 16 bit 0 channel 44100 Hz RIFF WAV audio.
File xxx.y4m is 176x144 29.97 fps mono video.
*** glibc detected *** /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example: munmap_chunk(): invalid pointer: 0x00007fffffffdb30 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x76628)[0x7ffff7864628]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x4a4505]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x504090]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x40535d]
/lib64/libc.so.6(__libc_start_main+0xe6)[0x7ffff780cc36]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x40a039]
======= Memory map: ========
00400000-0063a000 r-xp 00000000 08:08 6452963 /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example
00839000-0083a000 r--p 00239000 08:08 6452963 /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example
0083a000-0083b000 rw-p 0023a000 08:08 6452963 /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example
0083b000-008e6000 rw-p 00000000 00:00 0 [heap]
7ffff75d7000-7ffff75ed000 r-xp 00000000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff75ed000-7ffff77ec000 ---p 00016000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff77ec000-7ffff77ed000 r--p 00015000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff77ed000-7ffff77ee000 rw-p 00016000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff77ee000-7ffff795c000 r-xp 00000000 08:07 131081 /lib64/libc-2.11.3.so
7ffff795c000-7ffff7b5b000 ---p 0016e000 08:07 131081 /lib64/libc-2.11.3.so
7ffff7b5b000-7ffff7b5f000 r--p 0016d000 08:07 131081 /lib64/libc-2.11.3.so
7ffff7b5f000-7ffff7b60000 rw-p 00171000 08:07 131081 /lib64/libc-2.11.3.so
7ffff7b60000-7ffff7b65000 rw-p 00000000 00:00 0
7ffff7b65000-7ffff7bc0000 r-xp 00000000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7bc0000-7ffff7dbf000 ---p 0005b000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7dbf000-7ffff7dc0000 r--p 0005a000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7dc0000-7ffff7dde000 rw-p 0005b000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7dde000-7ffff7dfd000 r-xp 00000000 08:07 131074 /lib64/ld-2.11.3.so
7ffff7f24000-7ffff7fc1000 rw-p 00000000 00:00 0
7ffff7fc8000-7ffff7ff8000 rw-p 00000000 00:00 0
7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0 [vvar]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 0001e000 08:07 131074 /lib64/ld-2.11.3.so
7ffff7ffd000-7ffff7ffe000 rw-p 0001f000 08:07 131074 /lib64/ld-2.11.3.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
OggSa8W!۰ہ*theora
°u0迵@
Program received signal SIGABRT, Aborted.
0x00007ffff7820b55 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff7820b55 in raise () from /lib64/libc.so.6
#1 0x00007ffff7822131 in abort () from /lib64/libc.so.6
#2 0x00007ffff785ee0f in __libc_message () from /lib64/libc.so.6
#3 0x00007ffff7864628 in malloc_printerr () from /lib64/libc.so.6
#4 0x00000000004a4505 in oggpack_writeclear (b=b@entry=0x7fffffffda10) at bitwise.c:251
#5 0x0000000000504090 in vorbis_analysis_headerout (v=v@entry=0x7fffffffdcb0, vc=vc@entry=0x7fffffffdb50, op=op@entry=0x7fffffffdba0, op_comm=op_comm@entry=0x7fffffffdbd0, op_code=op_code@entry=0x7fffffffdc00) at info.c:645
#6 0x000000000040535d in main (argc=<optimized out>, argv=<optimized out>) at encoder_example.c:1688
(gdb) detach
files attached:
weird, I can not attach file here, so if you need please contact me for the the crash sample.
```
This issue has been assigned a CVE number :CVE-2017-14632
https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2320ogginfo -q could be quieter2017-07-05T07:17:14ZTristan Millerogginfo -q could be quieterAccording to the built-in usage instructions and the man page, `ogginfo` has a "quiet" command-line option:
```
-q Make less verbose. Once will remove detailed informative
messages, two will remove warnings
```
Howev...According to the built-in usage instructions and the man page, `ogginfo` has a "quiet" command-line option:
```
-q Make less verbose. Once will remove detailed informative
messages, two will remove warnings
```
However, even when using this option multiple times, `ogginfo` always prints logging information about what file(s) it's processing:
```
$ ogginfo -q -q somefile.ogg
Processing file "somefile.ogg"...
```
Can I suggest that this logging information be suppressed when `-q` is used (or at least when it's used twice, or maybe even three times)? I sometimes want to call `ogginfo` from a shell script where all I care about is the return value, and any output at all is bothersome. I guess I could just redirect stdout to `/dev/null`, but many other tools that support a "quiet" flag do indeed suppress all non-essential informational output.https://gitlab.xiph.org/xiph/vorbis/-/issues/2327vorbisfile free of uninitialized memory if seek fails2019-01-28T23:01:57ZGitlab Botvorbisfile free of uninitialized memory if seek failsIn vorbisfile.c, it is possible for ov_raw_seek to free some uninitialized memory (and therefore crash) if seek fails. I attach a patch to fix this bug.
This was originally discovered by an SFML user in this bug, and I investigated it a...In vorbisfile.c, it is possible for ov_raw_seek to free some uninitialized memory (and therefore crash) if seek fails. I attach a patch to fix this bug.
This was originally discovered by an SFML user in this bug, and I investigated it a bit more:
https://github.com/SFML/SFML/issues/1241Thomas DaedeThomas Daedehttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2326Icecast- 2.4.3 Do not publish directory yp2017-10-05T10:40:40ZGitlab BotIcecast- 2.4.3 Do not publish directory ypI run icecast 2.4.3 with correct configuration and it does not publish in YP directory.
With the same configuration, version 2.4.1 publishes correctly in directory YPI run icecast 2.4.3 with correct configuration and it does not publish in YP directory.
With the same configuration, version 2.4.1 publishes correctly in directory YPThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/opusfile/-/issues/2325Double Free in opusfile2020-06-24T22:38:19ZGitlab BotDouble Free in opusfileAs part of our [fuzzing](https://www.owasp.org/index.php/Fuzzing) efforts at Google, we have identified an issue in git HEAD of opusfile. To reproduce requires compiling the project with the LLVM compiler, taking advantage of the saniti...As part of our [fuzzing](https://www.owasp.org/index.php/Fuzzing) efforts at Google, we have identified an issue in git HEAD of opusfile. To reproduce requires compiling the project with the LLVM compiler, taking advantage of the sanitizers that it offers (this issue was discovered using [AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer).
To reproduce you will need to build your project using that sanitizer, and execute the attached stub code on the reproducer input that we have also provided. This stub code could also serve as a useful template for
fuzzing in your project with l[libFuzzer](http://libfuzzer.info) and/or [AFL](http://lcamtuf.coredump.cx/afl/), which may help you uncover additional issues. Some documentation on how to get started with libFuzzer is here:
- [Getting Started Documentation](http://llvm.org/docs/LibFuzzer.html#getting-started)
- [LibFuzzer Tutorial](http://llvm.org/docs/LibFuzzer.html#getting-started)
- [OSS-Fuzz target example](https://github.com/google/oss-fuzz/blob/a143b9b39a51412d133f846688194d68fe4197ba/projects/libchewing/chewing_default_fuzzer.c)
The following options / environment variables may be necessary for
accurate reproduction of the issue as well:
```
ASAN_OPTIONS="exitcode=1,handle_segv=1,detect_leaks=1,leak_check_at_exit=1,a
llocator_may_return_null=1,detect_odr_violation=0"
MSAN_OPTIONS=...
}}}
The sanitizer error that we encountered is here:
{{{
==779726==ERROR: LeakSanitizer: detected memory leaks
SUMMARY: AddressSanitizer: 78 byte(s) leaked in 4 allocation(s).
}}}
Other relevant info/repro instructions:
{{{
** Repro:
git clone https://git.xiph.org/opusfile.git
sudo apt-get install libogg-dev libopus-dev
CC="clang-3.8" CFLAGS="-O1 -g -fsanitize=address,bool,float-cast-overflow,integer-divide-by-zero,return,returns-nonnull-attribute,shift-exponent,unreachable,vla-bound -fno-sanitize-recover=all -fno-omit-frame-pointer -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION=1" CXX="clang++-3.8" CXXFLAGS="-O1 -g -fsanitize=address,bool,float-cast-overflow,integer-divide-by-zero,return,returns-nonnull-attribute,shift-exponent,unreachable,vla-bound -fno-sanitize-recover=all -fno-omit-frame-pointer -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION=1" LDFLAGS="-g -fsanitize=address,bool,float-cast-overflow,integer-divide-by-zero,return,returns-nonnull-attribute,shift-exponent,unreachable,vla-bound" ./configure && make
./examples/opusfile_example ./34286806_leak-c99edf095c8159361c13c868fbf7b257371a4007-min
** Analysis:
The issue is in src/info.c.
This call to opus_tags_parse_impl() fails, and opus_tags_clear() is called:
226 ret=opus_tags_parse_impl(&tags,_data,_len);
227 if(ret<0)opus_tags_clear(&tags);
It fails at this line:
192 _data+=4;
193 len-=4;
194 if(count>len)return OP_EBADHEADER;
because count = 0x43000026 and length = 0x26.
Then at this line:
99 for(ci=ncomments;ci-->0;)_ogg_free(_tags->user_comments[ci]);
It frees memory that I don't think was ever allocated:
_tags->user_comments[ci] => 0xbebebebebebebebe
```
We will gladly work with you so you can successfully confirm and reproduce
this issue. Do let us know if you have any feedback surrounding the
documentation.
Once you have reproduced the issue, we’d appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the
report to “Google Autofuzz project”.
We are also pleased to inform you that your project is also eligible for
inclusion to the OSS-Fuzz project, which can provide additional continuous
fuzzing, and encourage you to investigate [https://github.com/google/oss-
fuzz/blob/master/docs/new_project_guide.md integration options].
Don’t hesitate to let us know if you have any questions!
Google AutoFuzz Teamhttps://gitlab.xiph.org/xiph/opusfile/-/issues/2324opus_tags_parse_impl: Fix free of uninitialised data2020-06-24T22:38:19ZGitlab Botopus_tags_parse_impl: Fix free of uninitialised dataAs part of our [fuzzing](https://www.owasp.org/index.php/Fuzzing) efforts at Google, we have identified an issue in git HEAD of opusfile. To reproduce requires compiling the project with the LLVM compiler, taking advantage of the saniti...As part of our [fuzzing](https://www.owasp.org/index.php/Fuzzing) efforts at Google, we have identified an issue in git HEAD of opusfile. To reproduce requires compiling the project with the LLVM compiler, taking advantage of the sanitizers that it offers (this issue was discovered using [AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer).
To reproduce you will need to build your project using that sanitizer, and execute the attached stub code on the reproducer input that we have also provided. This stub code could also serve as a useful template for fuzzing in your project with l[libFuzzer](http://libfuzzer.info) and/or [AFL](http://lcamtuf.coredump.cx/afl/), which may help you uncover additional issues. Some documentation on how to get started with libFuzzer is here:
- [Getting Started Documentation](http://llvm.org/docs/LibFuzzer.html#getting-started)
- [LibFuzzer Tutorial](http://llvm.org/docs/LibFuzzer.html#getting-started)
- [OSS-Fuzz target example](https://github.com/google/oss-fuzz/blob/a143b9b39a51412d133f846688194d68fe4197ba/projects/libchewing/chewing_default_fuzzer.c)
The following options / environment variables may be necessary for accurate reproduction of the issue as well:
```
ASAN_OPTIONS="exitcode=1,handle_segv=1,detect_leaks=1,leak_check_at_exit=1,a llocator_may_return_null=1,detect_odr_violation=0"
MSAN_OPTIONS=...
```
The sanitizer error that we encountered is here:
```
==834381==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000448ea4 bp 0x7fff554ee620 sp 0x7fff554ee5f0 T0)
==834381==The signal is caused by a READ memory access.
==834381==Hint: address points to the zero page.
```
Other relevant info/repro instructions:
```
The crash occurs during parsing of invalid user_comments tags.
I configured with:
CC=clang-3.6 CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" ./configure --enable-static --disable-shared
And built with:
clang-3.6 -fno-omit-frame-pointer -g -fsanitize=address -Iinclude -I /usr/include/opus/ -L .libs -o poc poc.c -lopusfile -logg -lopus
I'm not familiar with opusfile, but I think the chain of events is:
1. opus_tags_parse() is called, calls opus_tags_parse_impl()
2. opus_tags_parse_impl() starts parsing, gets an okay preamble and comment count of 1
3. opus_tags_parse_impl() calls op_tags_ensure_capacity() to allocate _tags->user_comments
4. opus_tags_parse_impl() user_comments parsing loop encounters a comment with a nonsensical length, returns with error *without* initialising the comment.
5. opus_tags_parse() calls opus_tags_clear() which has this test:
if(_tags->user_comments!=NULL)ncomments++;
for(ci=ncomments;ci-->0;)_ogg_free(_tags->user_comments[ci]);
It assumes that if _tags->user_comments was allocated, then its contents are valid but this isn't the case because of #4.
Always initialising _tags->user_comments[ci] in opus_tags_parse_impl() should be sufficient fix this.
```
Suggested fix in libopusfile/src/info.c:
```
if(_tags!=NULL) _tags->user_comments[ci]=NULL;
```
We will gladly work with you so you can successfully confirm and reproduce this issue. Do let us know if you have any feedback surrounding the documentation.
Once you have reproduced the issue, we’d appreciate to learn your expected timeline for an update to be released. With any fix, please attribute the report to “Google Autofuzz project”.
We are also pleased to inform you that your project is also eligible for inclusion to the OSS-Fuzz project, which can provide additional continuous fuzzing, and encourage you to investigate [ integration options](https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md).
Don’t hesitate to let us know if you have any questions!
Google AutoFuzz Team
https://gitlab.xiph.org/xiph/icecast-server/-/issues/2323m3u/xspf/vclt files do not support SSL2019-07-04T20:20:25ZGitlab Botm3u/xspf/vclt files do not support SSLRegardless of the settings within the config file, the url created in the m3u/xspf/vclt files is still in HTTP.
It looks to be due to the following lines in /src/fserve.c (lines 476 till 493) where the http is hardcoded:
```
if ...Regardless of the settings within the config file, the url created in the m3u/xspf/vclt files is still in HTTP.
It looks to be due to the following lines in /src/fserve.c (lines 476 till 493) where the http is hardcoded:
```
if (host == NULL)
{
config = config_get_config();
snprintf (httpclient->refbuf->data + ret, BUFSIZE - ret,
"http://%s:%d%s\r\n",
config->hostname, config->port,
sourceuri
);
config_release_config();
}
else
{
snprintf (httpclient->refbuf->data + ret, BUFSIZE - ret,
"http://%s%s\r\n",
host,
sourceuri
);
}
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2322gzip http compression for server pages.2019-01-09T11:59:13ZRoger Hågensengzip http compression for server pages.With Icecast 2.4.x there is no gzip compression used for served pages.
While most served pages are not that large, gzip may be the difference between a page being served in one TCP packet vs multiple.
And then there are monstrosity lik...With Icecast 2.4.x there is no gzip compression used for served pages.
While most served pages are not that large, gzip may be the difference between a page being served in one TCP packet vs multiple.
And then there are monstrosity like this http://relay.sonixcast.com/ that would clearly benefit from gzip.
gzip could even be applied to xml stats pages as PHP and other serverside scripting languages also support gzip.
While technical it may be possible to apply gzip to the actual stream I would not advise that, the benefit would be minimal in most cases and the compatibility issues with older players could be high (they may support gzip pages but not gzip audiostreams for example).
gzip should probably be enabled by default so that the "optimal" settings are enabled "out of the box".
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2319vorbiscomment: remove specific tags2018-01-22T04:18:25ZGitlab Botvorbiscomment: remove specific tagsIt should be possible to remove tags with `vorbiscomment`.
Suggested parameter format:
1. Remove a tag with a certain value, e.g. one of several ARTISTs in the file
`$ vorbiscomment -a file.ogg --rm ARTIST=foo`
2. Remove all art...It should be possible to remove tags with `vorbiscomment`.
Suggested parameter format:
1. Remove a tag with a certain value, e.g. one of several ARTISTs in the file
`$ vorbiscomment -a file.ogg --rm ARTIST=foo`
2. Remove all artist tags
`$ vorbiscomment -a file.ogg --rm ARTIST`
3. Remove an artist and add add two new (e.g. when splitting a comma separated artist into two artist fields)
`$ vorbiscomment -a file.ogg --rm ARTIST="Foo, Bar" -t ARTIST=Foo -t ARTIST=Bar`
Considerations:
* It is possible that a tag with the same value exists multiple times (2x `ARTIST=foo`). When issuing the command to remove `ARTIST=foo`, both should be removed in my eyes.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2318icecast fails to build against openssl-1.1 that lacks deprecated features2019-04-24T17:23:49ZGitlab Boticecast fails to build against openssl-1.1 that lacks deprecated featuresicecast-2.5_beta1 (and 2.4.3 as well) fails to build against openssl-1.1 that lacks deprecated features. This is the case when openssl-1.1 was built with either "--api=1.1.0" or "no-deprecated" option. The build issues look like this:
`...icecast-2.5_beta1 (and 2.4.3 as well) fails to build against openssl-1.1 that lacks deprecated features. This is the case when openssl-1.1 was built with either "--api=1.1.0" or "no-deprecated" option. The build issues look like this:
```
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I./common/ -Wall -ffast-math -fsigned-char -I/usr/include/libxml2 -I/usr/include -pthread -march=native -O2 -pipe -c -o connection.o connection.c
connection.c: In function ‘get_ssl_certificate’:
connection.c:195:5: warning: implicit declaration of function ‘SSL_load_error_strings’ [-Wimplicit-function-declaration]
SSL_load_error_strings(); /* readable error messages */
^
connection.c:196:5: warning: implicit declaration of function ‘SSL_library_init’ [-Wimplicit-function-declaration]
SSL_library_init(); /* initialize library */
^
connection.c:198:12: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
method = SSLv23_server_method();
^
```
And later in the linking part:
```
libtool: link: i686-pc-linux-gnu-gcc -pthread -march=native -O2 -pipe -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -o icecast cfgfile.o main.o logging.o sighandler.o connection.o global.o util.o slave.o source.o stats.o refbuf.o client.o xslt.o fserve.o admin.o md5.o format.o format_ogg.o format_mp3.o format_midi.o format_flac.o format_ebml.o format_kate.o format_skeleton.o format_opus.o event.o event_log.o event_exec.o acl.o auth.o auth_htpasswd.o auth_anonymous.o auth_static.o format_vorbis.o format_theora.o format_speex.o auth_url.o event_url.o yp.o -L/usr/lib -Wl,--as-needed common/net/.libs/libicenet.a common/thread/.libs/libicethread.a common/httpp/.libs/libicehttpp.a common/log/.libs/libicelog.a common/avl/.libs/libiceavl.a common/timing/.libs/libicetiming.a -lcurl -lnghttp2 -lidn2 -lssl -lcrypto -lspeex -ltheora -lvorbis -logg -lxslt -lxml2 -lz -ldl -lm -pthread
connection.o: In function `connection_accept_loop':
connection.c:(.text+0x736): undefined reference to `SSL_load_error_strings'
connection.c:(.text+0x73b): undefined reference to `SSL_library_init'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:512: icecast] Error 1
```
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/libao/-/issues/2317libao_pulse buffer calculation overflow2017-11-03T10:00:01ZGitlab Botlibao_pulse buffer calculation overflowIn tracking down the source of some strange behavior when setting buffer_time for the pulse plugin, I found a bug in the buffer length calculations that results in a multiplication overflow for some values. This overflow would set the bu...In tracking down the source of some strange behavior when setting buffer_time for the pulse plugin, I found a bug in the buffer length calculations that results in a multiplication overflow for some values. This overflow would set the buffer size to some absurdly-large value (~30 seconds in my case).
I've attached a patch that casts the multiplicands to a 64-bit int before the multiplication. This fixed the issue for me.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2316MP3 files sent by Icecast do not play on Chrome2018-08-27T12:34:43ZLaurensGMP3 files sent by Icecast do not play on ChromeI have a webpage with Jplayer to play .mp3 files from an Icecast server. Up to and including icecast version 2.4.0 this works on all browsers (Firefox, IE, Edge, Chrome on Windows; Firefox, Puffin, Chrome on Android). When using icecast ...I have a webpage with Jplayer to play .mp3 files from an Icecast server. Up to and including icecast version 2.4.0 this works on all browsers (Firefox, IE, Edge, Chrome on Windows; Firefox, Puffin, Chrome on Android). When using icecast versions 2.4.2 or 2.4.3 it works on all browsers except Chrome.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/oggdsf/-/issues/2315Windows Media Player fails with "there is a problem with your sound device" w...2018-04-29T07:18:11ZpropauliWindows Media Player fails with "there is a problem with your sound device" when playing .ogg on Windows Server 2012 R2i installed Desktop Experience on a Windows Server 2012 R2 server, rebooted and installed opencodecs opencodecs_0.85.17777.exe (downloaded via the link at vorbis.com). I'd like to use these to enable remote (rdp) users to play back .ogg ...i installed Desktop Experience on a Windows Server 2012 R2 server, rebooted and installed opencodecs opencodecs_0.85.17777.exe (downloaded via the link at vorbis.com). I'd like to use these to enable remote (rdp) users to play back .ogg recordings containing speech.
After installation Windows Media Player happily plays mp3 and wav files, but when clicking on a .ogg file Windows Media Player just gives an error message saying there was a problem with my sound device.
I have set up the same version of opencodecs and tried playing the same .ogg file on my local Win 10 desktop and it works just fine locally.
I suspect there's a compatiblity issue with Windows Server in oggdsf, as other media types actually play OK. Probably Media Player just isn't spitting out a useful error message.Cristian AdamCristian Adamhttps://gitlab.xiph.org/xiph/opus/-/issues/2314Opus 1.1.3 fixed and floating point code behavior difference while encoding a...2017-10-21T19:37:03Zpks831Opus 1.1.3 fixed and floating point code behavior difference while encoding and decoding 3 kHz sine tone at 48 kHz sampling rate.Hi,
The attached 16 bit stereo pcm file when encoded (at 8 kbps bitrate) and decoded with opus application (opus-1.1.3), produces quite different output for fixed (./configure --enable-fixed-point --disable-float-api) and floating po...Hi,
The attached 16 bit stereo pcm file when encoded (at 8 kbps bitrate) and decoded with opus application (opus-1.1.3), produces quite different output for fixed (./configure --enable-fixed-point --disable-float-api) and floating point builds. Floating point build gives close enough output to original pcm content, but for fixed point build there are a lot of amplitude fluctuations. Command lines used for encoding and decoding are given below:
Encoding:
./opus_demo -e voip 48000 2 8000 3229_sin_3000_stereo_fs_48000.pcm encoded.bit
Decoding:
./opus_demo -d 48000 2 encoded.bit out.pcm
Input pcm file is attached (16 bit PCM, 48 kHz Sampling Rate, Stereo)Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2313Add a history url2019-11-27T11:34:37ZRoger HågensenAdd a history urlA example url would be: http://127.0.0.1:8000/playing.json?mount=/live
The following is the minimum amount of information that a Webplayer or Website/Forum plugin/Blob plugin would need:
```
{
"server_name":"Testing Stuff",
"server_des...A example url would be: http://127.0.0.1:8000/playing.json?mount=/live
The following is the minimum amount of information that a Webplayer or Website/Forum plugin/Blob plugin would need:
```
{
"server_name":"Testing Stuff",
"server_description":"Blah blah blah",
"history":
[
{"date":"2017-03-03T10:52:10Z","artist":"Some artist","title":"Some song (this is the current one)"},
{"date":"2017-03-03T10:48:10Z","artist":"Some other artist 2","title":"Some Song 2"},
{"date":"2017-03-03T10:44:10Z","artist":"Artist 3","title":"Song 3"},
{"date":"2017-03-03T10:40:10Z","artist":"Artist 4","title":"Song 4"},
{"date":"2017-03-03T10:36:10Z","artist":"Artist 5","title":"Song 5"},
{"date":"2017-03-03T10:32:10Z","artist":"Artist 6","title":"Song 6"},
{"date":"2017-03-03T10:28:10Z","artist":"Artist 7","title":"Song 7"},
{"date":"2017-03-03T10:24:10Z","artist":"Artist 8","title":"Song 8"},
{"date":"2017-03-03T10:20:10Z","artist":"Artist 9","title":"Song 9"},
{"date":"2017-03-03T10:16:10Z","artist":"Artist 10","title":"Song 10"}
]
}
```
The server_name and server_description is included since those could change between DJs (and are nice to display in the webplayer to the listener).
The date for each song (ISO 8601 standard) is somewhat useful, not only can a webplayer show the start time for each song to the listener but (with the exception of the current song) it can calculate and show the duration of songs which a listener or visitor may find interesting.
JSON is convenient as it would need next to no processing by a server script before being passed to a Webplayer or used on a webpage via XHR.
Now as Icecast uses XML internally (mentioned on the icecast-dev mailing list recently) a alternative could be:
A example url would be: http://127.0.0.1:8000/playing.xml?mount=/live
And the following content:
```
<?xml version="1.0" encoding="UTF-8"?>
<source mount="/live">
<server_name>Testing Stuff</server_name>
<server_description>Blah blah blah</server_description>
<history>
<track>
<date>2017-03-03T10:52:10Z</date>
<artist>Some artist</artist>
<title>Some song (this is the current one)</title>
</track>
<track>
<date>2017-03-03T10:48:10Z</date>
<artist>Some other artist 2</artist>
<title>Some Song 2</title>
</track>
<track>
<date>2017-03-03T10:44:10Z</date>
<artist>Artist 3</artist>
<title>Song 3</title>
</track>
<track>
<date>2017-03-03T10:40:10Z</date>
<artist>Artist 4</artist>
<title>Song 4</title>
</track>
<track>
<date>2017-03-03T10:36:10Z</date>
<artist>Artist 5</artist>
<title>Song 5</title>
</track>
<track>
<date>2017-03-03T10:32:10Z</date>
<artist>Artist 6</artist>
<title>Song 6</title>
</track>
<track>
<date>2017-03-03T10:28:10Z</date>
<artist>Artist 7</artist>
<title>Song 7</title>
</track>
<track>
<date>2017-03-03T10:24:10Z</date>
<artist>Artist 8</artist>
<title>Song 8</title>
</track>
<track>
<date>2017-03-03T10:20:10Z</date>
<artist>Artist 9</artist>
<title>Song 9</title>
</track>
<track>
<date>2017-03-03T10:16:10Z</date>
<artist>Artist 10</artist>
<title>Song 10</title>
</track>
</history>
</source>
```
The XML is not quite as elegant as the JSON but it gets the job done and I'd rather see it as XML than never as JSON.
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/opus-tools/-/issues/2312Opus 32kbps file+cue split file after 6h45m23s787ms2018-05-13T08:51:37ZAndrey VolkovOpus 32kbps file+cue split file after 6h45m23s787msopus codec 32kbps (libopus 1.2-alpha and stable libopus 1.1.4)
flag --ignorelength
I have no select another flags or additions before converting.
mode: some files to one file+cue
Result:
Split on two pieces ("name"+"name" part 2+cue) ...opus codec 32kbps (libopus 1.2-alpha and stable libopus 1.1.4)
flag --ignorelength
I have no select another flags or additions before converting.
mode: some files to one file+cue
Result:
Split on two pieces ("name"+"name" part 2+cue) after convert, 6h45m23s:787ms instead of one file+cue
http://imgur.com/hMxjieg
http://imgur.com/cuap5X4
http://imgur.com/fkXSZ2J
http://imgur.com/zc72Kp7
I try two versions of codec in aimp converter (opusenc.exe) and convert another long record. Similar time when codec create another part.
http://imgur.com/8LRgphY
sorry for my english.
We tryin find the answer on aimp forum thread.
http://www.aimp.ru/forum/index.php?topic=55679.0
Andrey VolkovAndrey Volkovhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2311Parametrize TLS/SSL Protocol in Icecast config file2021-09-28T12:50:45ZGitlab BotParametrize TLS/SSL Protocol in Icecast config fileWe currently have the option of enabling SSL, defining ciphers and certificate files. Would you please add the option to define the protocol.
Example could be:
```
<SSL_Protocol>SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1|SSL_OP_NO_SSLv2|SSL_OP_...We currently have the option of enabling SSL, defining ciphers and certificate files. Would you please add the option to define the protocol.
Example could be:
```
<SSL_Protocol>SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1|SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3</SSL_Protocol>
```
The current ability to define ciphers is great but some ciphers are backwards compatible. From a security standpoint, it would be great to be able to control the protocols available.
Is there a workaround for me without needing to recompile as I've installed from Xiph repository.
Thank you so much for your time!Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2310re-license to "GPL-2. with OpenSSL exception"2018-06-16T20:52:48ZJamiere-license to "GPL-2. with OpenSSL exception"The debian version of icecast2 doesn't ship with openssl, which means we can't embed streams in https pages without a mixed-content warning.
The debian maintainers report that [it is due to a openssl licensing conflict](https://bugs.deb...The debian version of icecast2 doesn't ship with openssl, which means we can't embed streams in https pages without a mixed-content warning.
The debian maintainers report that [it is due to a openssl licensing conflict](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815#15) that could be resolved if icecast2 could be re-licensed to include an exception for openssl (among other options).
Is that option viable? Other options?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2309Can't connect to Icecast server from multiple tabs in Firefox2019-05-13T11:49:02ZugultopuCan't connect to Icecast server from multiple tabs in Firefox
## Steps to Reproduce
1. Open Firefox 50.1.0.
2. Connect to an Icecast mount point. The stream will start.
3. Open a new tab and try to connect to the same mount point. The connection won't be established.
4. Open a Private Window and t...
## Steps to Reproduce
1. Open Firefox 50.1.0.
2. Connect to an Icecast mount point. The stream will start.
3. Open a new tab and try to connect to the same mount point. The connection won't be established.
4. Open a Private Window and try to connect to the same mount point. The stream will start.
5. Open another tab in the Private Window and try to connect to the same mount point. The connection won't be established.
## Actual Results
Can't establish connection to an Icecast server from multiple tabs in Firefox.
## Expected Results
Establish connection to an Icecast server from multiple tabs in Firefox.
## Notes
1. The issue does not occur on Chrome. It is possible to connect to a mount point from as many tabs as you like.Thomas B. RückerThomas B. Rücker