On 22/08/22 03:42PM, Mike Gilbert wrote: > On Mon, Aug 22, 2022 at 2:10 PM Kenton Groombridge <conc...@gentoo.org> wrote: > > What do you think? > > I am concerned that people will start mass filing bugs with > suggestions without fully understanding them or without testing them > thoroughly. Please don't do that. >
I had thought of this potentially being a problem as well. I think with this in mind perhaps it would be better to start with creating some documentation on these systemd service options on the wiki, with notes geared for both users and developers and when these options would/would not be a good idea to enable from both perspectives. That way we can at least have some solid reference material when addressing such bugs and providing guidance to developers to improve systemd units in their packages. > Also, ideally we would not need to provide systemd units at a distro > level, and they would instead be provided by upstream. I certainly > don't want to start installing distro-customized units where upstream > already provides unit files. > I agree! Unfortunately I know of a very small amount of packages where hardened systemd unit files are available but are not supported by upstream. One such upstream includes a hardened systemd unit in their contrib/, but nevertheless it is not installed by default for fear of breaking users' configurations. I think the best way to address this is to have packages ship unit override files instead of unit files themselves which enable these options. For example, instead of Gentoo shipping a modified miniflux.service unit file, we can instead install a file to /etc/system/miniflux.service.d/00gentoo.conf using the existing systemd_install_serviced helper in systemd.eclass which enables these options. Then, over time we can merge the modifications we make upstream if upstream wants them. If not, we can continue to ship this override file without changing how the original unit file gets installed.
signature.asc
Description: PGP signature
