On 11.01.20 21:32, Daniel Shahaf wrote: > Good morning Salvatore, > > Salvatore Bonaccorso wrote on Sat, Jan 11, 2020 at 09:07:30 +0100: >> Control: clone 948634 -1 >> Control: reassign -1 src:binutils >> Control: retitle -1 binutils: Please add a README.Debian.security >> documenting security support for binutils >> Control: blocked 948634 with -1 >> >> On Sat, Jan 11, 2020 at 02:28:14AM +0000, Daniel Shahaf wrote: >>> +++ b/security-support-limited >>> @@ -7,7 +7,7 @@ >>> -binutils Not covered by security support >>> +binutils Only suitable for trusted content; see >>> https://lists.debian.org/msgid-search/[email protected] >>> ganglia See README.Debian.security, only supported behind an >>> authenticated HTTP zone, #702775 >>> ganglia-web See README.Debian.security, only supported behind an >>> authenticated HTTP zone, #702776 >>> glpi Only supported behind an authenticated HTTP zone for >>> trusted users >>> >>> @Florian That linked message is yours; any objections from you? >> >> yes we can add that, but OTOH we asked the binutils maintainer already >> when we decided to mark it as unsupported, to please add a >> README.Debian.security file shipped in the package with a explanation, >> similar to the above, that there is none covering binutils by security >> updates (including upstream!). That would then be a slightly better >> reference to add, so I would rather go with that. > > Yes, this make sense: binutils would document its own support status and > security-support-limited would simply point to README.Debian.security, as > it does for some other packages. > >> The README.Debian.security file could contain something along the >> following lines: >> >>> binutils (the tools the included libraries like libbfd) are not >>> covered by security support, i.e. bugfixes are not backported to >>> stable releases and will only land in the next release. >> >> Matthias, could you add this? > > I suggest to state not only the negative promise ("no security support") but > also the positive one (e.g., "Only suitable for use on trusted content"). > > Nitpicking: Suggest to change "next release" either to "next release > (bullseye)" > or to "next point release" to clarify the intended meaning. > > Thanks for the quick answer,
I won't add such a file. Most issues are about the stack unwinder. So you should file same requests for any package using libiberty. the unwinder changed a lot. Does this still apply to the current unstable package? Matthias
