Looks like all 3 systemd units are affected. QA Notice: systemd units using /etc/conf.d detected: usr/lib/systemd/system/shorewall.service:EnvironmentFile=/etc/conf.d/shorewall usr/lib/systemd/system/shorewall6.service:EnvironmentFile=/etc/conf.d/shorewall6 See: https://wiki.gentoo.org/wiki/Project:Systemd/conf.d_files
This is known. I am closing this as WON'T FIX. Please read the discussion I had with mgorny in the past: https://github.com/gentoo/gentoo-portage-rsync-mirror/pull/101 tl;dr It's the upstream project which reads a configuration file. I am not going to patch shorewall for Gentoo just for systemd. Feel free to convince upstream to change anything but I won't do that because for me that's a false positive: I.e. there's nothing wrong with sourcing an ENV file in systemd. In Gentoo we added this check because /etc/conf.d could contain shell code in OpenRC times. But I expect that every systemd user knows that this file doesn't support shell code in systemd when sourced as EnvironmentFile and per default it doesn't contain shell code.
(In reply to Thomas Deutschmann from comment #1) > This is known. I am closing this as WON'T FIX. Please read the discussion I > had with mgorny in the past: > https://github.com/gentoo/gentoo-portage-rsync-mirror/pull/101 > > > tl;dr > > It's the upstream project which reads a configuration file. > > I am not going to patch shorewall for Gentoo just for systemd. Feel free to > convince upstream to change anything but I won't do that because for me > that's a false positive: > > I.e. there's nothing wrong with sourcing an ENV file in systemd. In Gentoo > we added this check because /etc/conf.d could contain shell code in OpenRC > times. But I expect that every systemd user knows that this file doesn't > support shell code in systemd when sourced as EnvironmentFile and per > default it doesn't contain shell code. The QA issue isn't about whether it is OK to source an env file, it's about whether it is OK to use an OpenRC file, which systemd should not depend on. They are two completely separate init systems and should be treated as such. I don't see the conclusion that this QA issue should be avoided in your link. If your concern is that the same env file needs to be used by all of the services, I don't see anything that prevents you from doing that. The only QA issue here is that that file can't an OpenRC file.
Well... somewhere in future I'll implement the solution discussed in https://github.com/gentoo/gentoo-portage-rsync-mirror/pull/101#issuecomment-95185579 I.e. creating /etc/systemd/system/shorewall-init.service.d/00gentoo.conf per service... But this will require testing which I can't do at my own at the moment.
usr-merge_tinderbox has reproduced this issue with version 5.2.8-r1 - Updating summary.
