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)
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).
