Re: Cleaning out Lintian's "Experimental: yes" tags

Soren Stoutner <[email protected]> Mon, 05 Jan 2026 12:48:07 -0700

Newsgroups	gmane.linux.debian.devel.quality-assurance,gmane.linux.debian.devel.lint.devel
Organization	Debian
Message-ID	<3519896.5fSG56mABF@soren-desktop>

On Monday, January 5, 2026 12:42:53 PM Mountain Standard Time Louis-Philippe 
Véronneau wrote:
> On 1/5/26 2:09 PM, Soren Stoutner wrote:
> 
> > On Sunday, January 4, 2026 3:09:12 AM Mountain Standard Time Holger Levsen
> > wrote:
> 
> >>> * update-debian-copyright
> >>>
> >>>
> >>>
> >>>   - last updated: 2022-12
> >>>   - 22,597 entries in UDD
> >>>   - This tag was highly controversial when it was implemented and I don't
> >>>   see
> >>>   its usefulness.:
> >> :
> >> :) I'd move it to pedantic.
> > 
> > 
> > This tag has been useful to me more than once.
> 
> 
> I'm curious to know how. As I've stated in another message in this 
> thread, updating your copyright notice yearly isn't required.

It catches those situations where I intended to update the copyright and forgot.

> >>> * systemd-service-file-missing-hardening-features
> >>>
> >>>
> >>>
> >>>   - last updated: 2018-12
> >>>   - 6,458 entries in UDD
> >>>   - This check only looks if the systemd service file includes at least 1
> >>>   feature in a long list of "hardening" features. IMO, this is an overly
> >>>   simplistic solution to a very hard problem.
> >> 
> >> agreed.
> > 
> > 
> > I think this is useful because otherwise I would never have known that some
> > of my packages are missing hardening features.
> 
> 
> My main problem is that "hardening a systemd service file" isn't binary 
> and this check is.
> 
> I think the goal of having hardened systemd service files is right and 
> we should work towards this, but this tag isn't good enough to do so and 
> might even give people a false sense of security.
> 
> Are you interested in having a look at this tag and helping it making 
> better? If so, I can keep it as "Experimental: yes" for the time being.

I completely agree that this check needs to be improved.  However, the current check is 
better than nothing.  So, if an improved check can be provided, it should replace this.  
Otherwise, I think the current check should remain.

-- 
Soren Stoutner
[email protected]

signature.asc (application/pgp-signature, 833 B)