On 27.01.2016 09:05, Anton Khirnov wrote:
> Quoting Andreas Cadhalpun (2016-01-27 01:18:23)
>> Could you explain in more detail what problem that would cause?
>> The whitelist should simply be passed from http to tcp in that case.
>
> You have to go over all the (de)muxers that call the protocol l
Quoting Andreas Cadhalpun (2016-01-27 01:15:07)
> On 26.01.2016 09:52, Luca Barbato wrote:
> > On 26/01/16 01:02, Andreas Cadhalpun wrote:
> >> On 22.01.2016 00:34, Luca Barbato wrote:
> >>> The ways to fix the specific problem problem:
> >>>
> >>> - provide a blacklist/whitelist option in hls (fro
On 01/27/2016 01:21 PM, Luca Barbato wrote:
> On 27/01/16 12:10, Peter B. wrote:
>> I'm a user of "concat" for creating lossy access-copies of segmented
>> lossless archival files.
>> This is done in one step, integrated in an automated mass-digitization
>> workflow.
> You can use hls as an editlis
On 27/01/16 12:10, Peter B. wrote:
>
> On 01/27/2016 09:05 AM, Anton Khirnov wrote:
>> I don't really understand your position -- on one hand you don't want to
>> remove "useful" functionality, even though the concat protocol is IMO
>> borderline-useless. OTOH you are quite fine with breaking appl
On 01/27/2016 09:05 AM, Anton Khirnov wrote:
> I don't really understand your position -- on one hand you don't want to
> remove "useful" functionality, even though the concat protocol is IMO
> borderline-useless. OTOH you are quite fine with breaking applications
> by adding restrictive defaults.
Quoting Andreas Cadhalpun (2016-01-27 01:18:23)
> On 26.01.2016 19:42, Anton Khirnov wrote:
> > Quoting Andreas Cadhalpun (2016-01-26 01:02:04)
> >> On 22.01.2016 13:37, Anton Khirnov wrote:
> >>> Just so it's clear what we're talking about, what is "properly" for you?
> >>
> >> That would be a mor
On 27.01.2016 01:21, Luca Barbato wrote:
> On 27/01/16 01:15, Andreas Cadhalpun wrote:
>> I think that at the very least the hls demuxer should always reject protocols
>> internal to libavformat, like concat, as those simply do not belong into a
>> hls
>> playlist.
>
> There is a patch from yours
On 27/01/16 01:15, Andreas Cadhalpun wrote:
> I think that at the very least the hls demuxer should always reject protocols
> internal to libavformat, like concat, as those simply do not belong into a hls
> playlist.
There is a patch from yours truly that does that, you are welcome to +1
it =)
co
Hi Rémi,
On 26.01.2016 19:49, Rémi Denis-Courmont wrote:
> On Thursday 21 January 2016 23:03:25 Andreas Cadhalpun wrote:
>> Why not fix the issue properly instead of removing useful functionality?
>
> By its very essence, the concat protocol allows for injection attacks with
> untrusted URLs (th
On 26.01.2016 19:42, Anton Khirnov wrote:
> Quoting Andreas Cadhalpun (2016-01-26 01:02:04)
>> On 22.01.2016 13:37, Anton Khirnov wrote:
>>> Just so it's clear what we're talking about, what is "properly" for you?
>>
>> That would be a more or less general mechanism, which would have prevented
>> t
On 26.01.2016 09:52, Luca Barbato wrote:
> On 26/01/16 01:02, Andreas Cadhalpun wrote:
>> On 22.01.2016 00:34, Luca Barbato wrote:
>>> The ways to fix the specific problem problem:
>>>
>>> - provide a blacklist/whitelist option in hls (from me, first
>>> solution)-> Anton disliked it since it is to
Hello,
On Thursday 21 January 2016 23:03:25 Andreas Cadhalpun wrote:
> Why not fix the issue properly instead of removing useful functionality?
By its very essence, the concat protocol allows for injection attacks with
untrusted URLs (the same super-class of vulnerabilities as XSS and SQL
in
Quoting Andreas Cadhalpun (2016-01-26 01:02:04)
> On 22.01.2016 13:37, Anton Khirnov wrote:
> > Just so it's clear what we're talking about, what is "properly" for you?
>
> That would be a more or less general mechanism, which would have prevented
> the information leak in the hls demuxer by defau
On 26/01/16 01:02, Andreas Cadhalpun wrote:
> On 22.01.2016 00:34, Luca Barbato wrote:
>> Let's try to make sure we are talking about the same problem here.
>>
>> by using hls you might craft a playlist containing a concat of a
>> playlist w/out a final new line.
>>
>> So you would send the initial
On 22.01.2016 00:34, Luca Barbato wrote:
> Let's try to make sure we are talking about the same problem here.
>
> by using hls you might craft a playlist containing a concat of a
> playlist w/out a final new line.
>
> So you would send the initial part of the file together with the url.
>
> This
Quoting Andreas Cadhalpun (2016-01-21 23:03:25)
> On 20.01.2016 13:42, Anton Khirnov wrote:
> > It is of very limited usefulness and is a source of important security
> > problems.
> >
> > Bug-Id: CVE-2016-1897
> > Bug-Id: CVE-2016-1898
> > ---
> > Changelog| 1 +
> > doc/protoc
On 21/01/16 23:35, Andreas Cadhalpun wrote:
> On 21.01.2016 23:21, Luca Barbato wrote:
>> On 21/01/16 23:03, Andreas Cadhalpun wrote:
>>> Why not fix the issue properly instead of removing useful functionality?
>>
>> It is not exactly useful (since it is quite unwieldy)
>
> But I'm sure it's used
On 21.01.2016 23:21, Luca Barbato wrote:
> On 21/01/16 23:03, Andreas Cadhalpun wrote:
>> Why not fix the issue properly instead of removing useful functionality?
>
> It is not exactly useful (since it is quite unwieldy)
But I'm sure it's used in quite some scripts.
> and the initial
> infrastru
On 21/01/16 23:03, Andreas Cadhalpun wrote:
> Why not fix the issue properly instead of removing useful functionality?
It is not exactly useful (since it is quite unwieldy) and the initial
infrastructure to policy path and protocols is already in the ml.
So the two are sort of orthogonal.
Concat
On 20.01.2016 13:42, Anton Khirnov wrote:
> It is of very limited usefulness and is a source of important security
> problems.
>
> Bug-Id: CVE-2016-1897
> Bug-Id: CVE-2016-1898
> ---
> Changelog| 1 +
> doc/protocols.texi | 26 ---
> libavformat/Makefile | 1 -
>
On Wed, Jan 20, 2016 at 3:23 PM, Anton Khirnov wrote:
> Quoting Vittorio Giovara (2016-01-20 18:41:57)
>> On Wed, Jan 20, 2016 at 7:42 AM, Anton Khirnov wrote:
>> > It is of very limited usefulness and is a source of important security
>> > problems.
>> >
>> > Bug-Id: CVE-2016-1897
>> > Bug-Id: C
Quoting Vittorio Giovara (2016-01-20 18:41:57)
> On Wed, Jan 20, 2016 at 7:42 AM, Anton Khirnov wrote:
> > It is of very limited usefulness and is a source of important security
> > problems.
> >
> > Bug-Id: CVE-2016-1897
> > Bug-Id: CVE-2016-1898
> > ---
>
> I'm ok with removing this, however sh
On 20/01/16 18:41, Vittorio Giovara wrote:
> On Wed, Jan 20, 2016 at 7:42 AM, Anton Khirnov wrote:
>> It is of very limited usefulness and is a source of important security
>> problems.
>>
>> Bug-Id: CVE-2016-1897
>> Bug-Id: CVE-2016-1898
>> ---
>
> I'm ok with removing this, however shouldn't th
On Wed, Jan 20, 2016 at 7:42 AM, Anton Khirnov wrote:
> It is of very limited usefulness and is a source of important security
> problems.
>
> Bug-Id: CVE-2016-1897
> Bug-Id: CVE-2016-1898
> ---
I'm ok with removing this, however shouldn't this be followed by a
version bump of some sort?
I'm not
On Wednesday 20 January 2016 13:42:43 Anton Khirnov wrote:
> It is of very limited usefulness and is a source of important security
> problems.
I suggested it so obviously fine with me.
If someone really has a use for it, I´d suggest configuring it via out-of-band
options.
--
Rémi Denis-Courmo
It is of very limited usefulness and is a source of important security
problems.
Bug-Id: CVE-2016-1897
Bug-Id: CVE-2016-1898
---
Changelog| 1 +
doc/protocols.texi | 26 ---
libavformat/Makefile | 1 -
libavformat/allformats.c | 1 -
libavformat/concat.c |
26 matches
Mail list logo
