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