[vlc-devel] Releasing 3.0.12

Lyndon Brown jnqnfe at gmail.com
Sun Oct 11 18:46:09 CEST 2020


Forgot to mention, if anyone feels that any more of my stuff is worth
backporting, just send me a message and I'll prep it.

On Sun, 2020-10-11 at 17:12 +0200, Alexandre Janniaux wrote:
> Hi,
> 
> The changes look good to backport but I have a few remarks:
> 
> 1/ Some issues with the commit message, example:
> 
> 
>     transcode: fix broken --sout-transcode-sfilter option
> 
>     the capability is "sub source" not "spu source"
> 
>     this mistake came from 1f5744e9Signed-off-by: Rémi Denis-
> Courmont's avatarRémi Denis-Courmont <remi at remlab.net>

Hmm, that seems to be a bug in gitlab. It seems to be removing the
empty line before the signoff messages when displaying the messages,
and in this case it's joining it to the end of the last line because
that line happens to not end in a fullstop. I've added a fullstop and
repushed and it's correctly showing it the same as the rest now. This
is not a problem at all viewing in gitk or gitg locally. I only see it
in gitlab now that you've pointed it out.

> 2/ Incorrect naming in NEWS:
> Security
>  * Fixed combined use-after-free and double-free bug in MacOS
> preferences
>    interface.
>  * Socks password and FTP module password options now actually marked
> as
>    password type options instead of simple string type.
> 
> This does not look like a security issue if it's not a path
> where untrusted data is going through. It should probably be
> Crash fix instead.

I don't think that just because preferences data is considered trusted
that an issue like this should not be considered a security issue. A
double-free on Android for instance, asI picked up from something I
read the other day, means that any subsequent allocation request for
the same amount of memory gets allocated the address that was double-
free'd. If this was android related, it could thus hypothetically
create an opportunity that a maliciously crafted data stream could take
advantage of.

But whatever, perhaps on macOS it's not actually a real concern; it's
probably very unlikely for the right set of circumstances to align for
it to be taken advantage of anyway; and if you and Remi don't consider
it worth a mention, that's fine, I've dropped it. The important thing
is having the fix in place itself.

> I'm not sure for Sock password/FTP module password options,
> what is the PASSWORD type doing? Isn't it just a GUI hint?
> In this case, security is not the correct place to put that
> too and Misc is probably appropriate.

It causes GUIs to mask the password inputs such that the content is not
plainly visible, thus security related. But probably not worth
mentioning so I dropped it.

FWIW the news commit was just me offering up descriptions for some of
mine that might be newsworthy, I'm not necessarily expecting it to be
perfect and not tweaked before merge. There may be other items not news
worthy enough that you might want to remove before merging, and I'm
fine with that, edit as you see fit. In fact it can be merged into a
wider news update commit if you like. Do with it as you wish :)

> Regards,
> --
> Alexandre Janniaux
> Videolabs
> 
> On Sun, Oct 11, 2020 at 02:21:32AM +0100, Lyndon Brown wrote:
> > On Sat, 2020-10-10 at 09:16 +0200, Felix Paul Kühne wrote:
> > > Do you have things to backport? If yes, do it :)
> > 
> > I've just gone through all of the small fixes of mine that have
> > landed
> > recently to pick out those that I feel are most appropriate for and
> > worthy of inclusion into 3.0, and done the backporting where they
> > did
> > not cleanly cherry-pick.
> > 
> > The hashes of the 19 chosen are below, should it be useful. I've
> > pushed
> > them to the public branch linked below, along with a 20th commit
> > providing a quick fix to the chromaprint module labels (part of a
> > much
> > larger set of label fixes to submit for 4.x later) since that
> > becomes
> > visible in the prefs now after one of the fixes and is particularly
> > bad. I also included a 21st commit to update the news file with
> > relevant entries for them.
> > 
> > If it would be helpful to provide them in some other means, a set
> > of
> > attachments, a zip, an MR to your personal code.videolan.org repo,
> > just
> > let me know.
> > 
> > https://code.videolan.org/jnqnfe/vlc/-/tree/v3
> > 
> > 801dc62e81872a8402e451240d5b8a75273f0591
> > 73e00de604c85b82b0fd9d5e974572300ea4fb4b
> > 50e2350110042ccf2b88652418af0a953fbfca55
> > ae6af4007e7b957052ad88dee3af8958e31ca7f0
> > f9b5677ada19cff818737cbc4533f31376c4b90c
> > 90e1fe40dad7317426ffe980e8a05c8590984ed7
> > afc593fbfc1569d8b4b31ef19239d974fb231952
> > 9214590343c9b8d55a88efaa3ca1f3c16109d553
> > e85dd955278e08fbf309120f0a360b414f76815c
> > 8aeef92e21ab32170a0aed01e7215c5c13c1a12e
> > 546d0210895140a83d8ffe35ac257560a05fe3f8
> > eb7c25a7e29632ffe8f68bcfa649ab216c12148a
> > bc6700f7d1f5a483dc59f74fb42a1baacea716c1
> > 92654192d6c912a0448016d397d87be39aa95fdb
> > b407307b78575f90a64c4f2fb1103140f3458f16
> > 7c2f535afe995702fe6f7dd2bb17820541006caa
> > 886824ab7797dd5dc7c165144251c78cc4caf0db
> > 036be65ee6766e6dec18348e0a7c0137a6bdf795
> > 47e85ec553897b63949709a67600ca4e8b2bd778
> > 05e2f75ad01decaf1c83c7f45e6cabbf3833d5b1
> > 
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel



More information about the vlc-devel mailing list