note: 8.2204.1 is 8..2204.0 with just the fix cherry-picked. No other changes.
Rainer El sáb, 7 may 2022 a las 14:48, Salvatore Bonaccorso (<car...@debian.org>) escribió: > > Hi Michael, > > [looping in the sec-team for completeness] > > On Thu, May 05, 2022 at 10:19:38PM +0200, Michael Biebl wrote: > > Am 05.05.22 um 17:10 schrieb Salvatore Bonaccorso: > > > Source: rsyslog > > > Version: 8.2204.0-1 > > > Severity: grave > > > Tags: security upstream > > > Justification: user security hole > > > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > <t...@security.debian.org> > > > > > > Hi, > > > > > > The following vulnerability was published for rsyslog. Filling for now > > > as grave, but we might downgrade. Probably affected configurations are > > > not that common if I understood correctly, the advisory has some > > > comments about it as well[1]. > > > > Yeah, I think this feature is obscure enough (and not enabled by default) > > that non-RC severity is fine. > > Thinking a bit more on it I see two aspects: > > * Usually following recommendations one should not expose recievers to > public, which makes the risk considerably lower. > * Though still reciervers enable octed-framing by default. > > So I think to leave the severity actually as it is, and consider it RC > and at earliest point possible for you either do a cherry-picked > upload on top of 8.2204.0-1 or just upload 8.2204.1 to unstable, I > htink I would prefer the later. > > Secondly, about releasing a DSA, still slight borderline, but I think > we would be safer to release one. I can help rpepare updates for > bullseye and buster here if needed and wanted. I the git repository I > see 8.2102.0-2+deb11u1 as released for bullseye but this change > actually never landed to bullseye and was not acked by SRM? > > Regards, > Salvatore >
