Hi Thomas,
Thomas Ward <[email protected]> hat am 24.06.2026 04:11 CEST geschrieben:
The attempt to get this into trixie-pu was rejected by the
corresponding teams that manage updates as "it does not meet the
criterion for a pu update".
This is sad, but I have no say on that decision. I was not part of that
decision making process.
Accordingly, the Security Team indicated it does not meet a Security
update threshold, leaving the only 'solution' to this being to provide
an update in Backports.
If the wider ftp team chooses to reject this upload consistently, they
are thus setting a precedent that "insecure configuration files
shipped by default".
No, this does not set a precent that "insecure configuration files [are]
shipped by default" in so far as users of the nginx package would
benefit at large from distributing a fixed nxinx-snippets *in
trixie-backports*. I just tried it: If I as user want to install nginx,
the package nginx-snippets is not getting installed at all. This means
the nginx-snippets package simply is not relevant for the default
configuration of nginx. If you want to help make the default
configuration of nginx more secure, a more sustainable approach could be
to engage with the package maintainer of nginx to fix the shipped
default configuration in that package.
The relevant trixie-pu bug where this is discussed is at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1138593 where this
was originally rejected by Adrian Bunk:
> Backports is the right place for giving users the option to pick a
specific package from the next stable release if they need some
specific newer functionality.
If this is rejected by Backports or ftp master team, and Security is
unwilling to touch this, then I require that someone *far up in the
chain* for managing packages - way beyond me as a DM, so either
Security or a higher level ftp team member - reply to the original bug
of #1138590 detailing the following:
(1) why this is not suitable for trixie-pu (already established in
1138593),
(2) why *backports* is not the proper place for this as the larger
consensus by the team who approves things for trixie-updates or such
with proposed update bugs was that Backports was in fact the proper
place for this to land, and
(3) how this fails to qualify as a backport as 'new functionality' of
the newer configurations is being applied.
Should this still be rejected, I may have no option but to open a
larger discussion on a mailing list because at this point Security
told me to go the trixie-pu route, and the people in charge of that
route *and* the Security team after the trixie-pu was rejected said to
go the Backports route.
You're welcome, please do. This is the very purpose of having the
rejects being sent to the debian-backports list in the first place.
Best regards,
Micha
