Re: nginx-snippets_1.3~bpo13+1_amd64.changes REJECTED

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