[vlc-devel] [PATCH 2/3] vlm: print deprecation notice upon loading

Alexandre Janniaux ajanni at videolabs.io
Sat Sep 19 20:36:20 CEST 2020


Hi,

On Sat, Sep 19, 2020 at 07:55:10PM +0200, Pierre Ynard via vlc-devel wrote:
> Date: Sat, 19 Sep 2020 19:55:10 +0200
> From: Pierre Ynard <linkfanel at yahoo.fr>
> To: vlc-devel at videolan.org
> Subject: Re: [vlc-devel] [PATCH 2/3] vlm: print deprecation notice upon
>  loading
> User-Agent: Mutt/1.5.23 (2014-03-12)
>
> > Bridge and mosaic_bridge can probably work without VLM, but the VLM file
> > parser moved as a playlist-demux-like module would probably help the UX
> > to use it.
>
> I was thinking about that when filing #25130, but a VLM demux would have
> security implications, notably allowing many input sources to inject
> unsafe VLM commands; and it doesn't exactly fit within the change_safe()
> input options security model.
>
> Even if we move away from the VLM, I think it could be good to still
> offer support for all the existing *.vlm files out there, even if using
> a different back end for it. And that can certainly be a helpful step.
> But I'm not sure how to do it.

There's indeed security implications, but the case you describe needs
a relatively free kind of arbitrary write on the FS to create the VLM
configuration file that will gets parsed.

In general, maybe we can add a kind of «redirection tracking» mechanism
so that playlist leading to a VLM file are storing their origin so that
we can prevent the VLM demux from opening?

In more hacky way, we could add a `--enable-vlm` volatile option to
prevent this from automatically happening while being able to enable
it locally in the UI or other parts if the risk is serious.

We should probably consider how it should work before considering
how it should not be working though, in my opinion.

Regards,
--
Alexandre Janniaux
Videolabs


More information about the vlc-devel mailing list