On 2025/01/21 13:54, Antoine Jacoutot wrote:
> On Tue, Jan 21, 2025 at 10:22:19AM +0000, Stuart Henderson wrote:
> > On 2025/01/21 10:56, Atanas Vladimirov wrote:
> > > On 2025-01-21 02:37, Stuart Henderson wrote:
> > > > > > I tired to add support for *.sub (MicroDVD) subtitles type and it
> > > > > > seems
> > > > > > to work.
> > > > > > Any thought are welcome.
> > > >
> > > > patches should be generated with "make update-patches"
> > > >
> > > > > > Index: metadata.c
> > > > > > --- metadata.c.org
> > > > > > +++ metadata.c
> > > > > > @@ -146,6 +146,11 @@
> > > > > > strcpy(p, ".smi");
> > > > > > ret = access(file, R_OK);
> > > > > > }
> > > > > > + if (ret != 0)
> > > > > > + {
> > > > > > + strcpy(p, ".sub");
> > > > > > + ret = access(file, R_OK);
> > > > > > + }
> > > > > >
> > > > >
> > > > > Even if the rest of the code is littered with strcpy(), it feels like
> > > > > patches should not add more bad calls to it.
> > > >
> > > > That function has, I think, a possible 2? bytes overflow in some
> > > > conditions. The code added in this patch would only overwrite an
> > > > existing overflow from the strcpy just above the context in the diff.
> > > > To write some valid non-strcpy code for a patch you'd need to change
> > > > the rest of tge function. Or using a larger string for the filename
> > > > would fix the overflow without touching the strcpy.
> > > >
> > > > Avoiding strcpy in a patch to this codebase is really giving a false
> > > > sense of safety here though, imho. Filename strings are built up this
> > > > way in other parts of the code. Bobby Tables' mum says the SQL command
> > > > generation is dodgy too.
> > > >
> > > > Perhaps we should just remove the port. It's only minimally active
> > > > upstream now, there's no movement on reported security-related bugs,
> > > > and IIRC it's not really happy on a system without inotify.
> > > >
> > > > https://sourceforge.net/p/minidlna/bugs/361/
> > > > (stack buffer overflow triggerable by http request)
> > > >
> > > > https://sourceforge.net/p/minidlna/bugs/356/
> > > > (setuid without setgroups)
> > >
> > > Thanks for the answers and the feedback, I appreciate it.
> > >
> > > If this port get remove can you recommend any alternatives?
> > > I like that minidlna is small and simple and works well on my home LAN.
> >
> > I don't think there's anything that's really quite equivalent.
> >
> > Many DLNA servers seem to be complex Java-based things and a long
> > way from the far simpler minidlna/readymedia.
> >
> > Other than those and some toy-looking over-simple abandoned ones that
> > I found (unfortunately this is an area where support for the quirks
> > of various poor implementations in smart TVs etc are needed), I think
> > the main options for unix-like OS are probably these:
> >
> > - gerbera, it's relatively complex compared to minidlna, however
> > it _is_ at least actively maintained upstream (continuation of
> > mediatomb that used to be in ports; C++).
> >
> > - rygel, part of the GNOME ecosystem - I don't have a good handle
> > on it but it seems somewhere between minidlna and gerbera in
> > complexity. development doesn't seem as active as gerbera (but
> > maybe it doesn't need it as much - at least it doesn't seem to
> > have a complex-ish web ui or as much configurability)
>
> We used to have ports/x11/gnome/rygel.
> It got removed because it required systemd.
> Maybe things changed since...
ah, I missed that when I looked for it - might still be worth a look
but I am less optimistic now!
> > Neither are in ports at the moment but I don't think would be hard
> > to add - it's likely that we already have the required dependencies
> > for both.
> >
> > On the audio-specific side, various iterations of what used to
> > be slimserver (squeezeboxserver/logitech media server/Lyrion
> > music server) do DLNA, but navigating the chain of CPAN dependencies
> > makes it a bit of a nightmare to port).
> >
>
> --
> Antoine
>
