Hi Andreas, Andreas Henriksson wrote: > > > The Debian version contains a home-grown config file parsing > > > feature. This should rather be implemented by the daemon itself (if > > > needed, or the config file deprecated). > > > > I tend to disagree here. The config parsing feature could be > > implemented as patch against upstream to easier keep up with upstream > > changes. > > Not sure if we disagree or agree really. To clarify: > I don't think the config file parsing should be implemented > in the init script itself.
I understood you. And IMHO we disagree — at least unless config file parsing is added upstream to the daemon. But given that gpm is upstream more or less in maintenance mode, I have doubts that this will happen anytime soon. To be sure I've asked upstream and here's his reply: | hmm - is that person willing to implement it cleanly? | | In general, I am very happy if someone updates the code upstream and | if it is clean code - the more welcome it is But at least I won't implement that myself. And I don't want to get rid of the config file either, at least not until there's a good replacement for it. So we indeed agree that having the config file parsing inside the daemon would be nice. But we disagree on the alternative, because from my point of view deprecating the config file is not an option. > If you prefer carrying the implementation as a patch to the daemon, > well that's your call. No, I meant a patch against the upstream init.d script to not have to check upstream's init.d script for changes upon every new upstream release. (Which is the current case.) But thinking about it, you're right that this config file parser will also also be needed for .service file. So if we really want a .service file for gpm in Debian (and no patch for config file parsing inside the daemon is submitted), we need a wrapper script around the daemon which then can be used by the init script and the .service file to avoid code duplication. We though should be able to base that wrapper script on the current debian init.d script. And yes, once that works out (and maybe some slight patching of upstream's init.d script), I'll send that upstream. But I won't send incomplete or untested stuff to upstream. > (I see the old maintenance style was to not collaborate with upstream in > favour of wasting time on rebasing large patch-sets, but was naively > hoping that would change with the new maintenance. JFTR: I know the current upstream developer in real-life for many years and we even occassionally meet for lunch or so. (Without such a good contact to upstream, I probably wouldn't have adopted this package.) > > > The gpm daemon is one of those long-standing things which likely > > > contains alot of legacy code. It would be nice if the attack surface > > > could be limited by applying some of the systemd security features > > > to the service as a future further improvement. eg. Protect*, > > > Private*, *Privileges, *Capabilit*, etc. See: > > > https://www.freedesktop.org/software/systemd/man/systemd.exec.html > > > > I strongly disagree here and surely won't propagate that. From my > > point of view KISS is the far better security concept than adding > > systemd bloat. > > Security is bloat? No, security is important. systemd and especially linking against its libraries is bloat. It adds additional complexity and more complexity in most cases means _more_ attack surface and hence less security. We though can discuss about using Linux capabilities and setcap in the maintainer scripts if that helps to run gpm under a non-privileged user — usually with a fallback to run setuid. I'll probably also need to check if gpm works at all on non-linux architectures. At least FreeBSD has its own gpm-alike functionality already built-in, so there's probably no or at least less need for gpm on Debian GNU/kFreeBSD. Not sure about GNU/Hurd. Samuel probably can tell. Samuel: Does GNU/Hurd has mouse support on the console? Or does gpm work there? Any systemd feature which is only an option or so in a .service file, .tmpfiles file, etc. and which doesn't imply changes which make gpm non-working under other init systems present in Debian (sysv, openrc, etc.), are of course fine, too. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
