4 ms·

Not OP, but please do try to influence this policy if you can: 1. The commit message [1] does not mention any security implication. This is reasonable, because

by rfoo 5y ago

Not OP, but please do try to influence this policy if you can: 1. The commit message [1] does not mention any security implication. This is reasonable, because the patch is usually released to the public earlier and it makes sense to do some obfuscation, to deter patch-gappers. But note that this approach is not a controversy-free one. 2. But there is also no security announcement in stable release notes or any similar stuff. I don't know how to provide evidence of "something simply does not exist". 3. Check the timeline in the blog post. The bug being fixed in stable release (5.6.11 on 2022-02-23) marks the end of upstream's handling of this bug. Max then had to send the bug details to linux-distros list to kick off (another separate process) distro maintainers' response. If what you are maintaining is not a distro, good luck. Is this wrong-sounding enough? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d2231c5d74e13b2a0546fee6737ee4446017903 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

amluto 5y ago
#1 is intentional, for better or for worse. It’s certainly well-intentioned too, although the intentions may be based on wrong assumptions. #2: upstream makes no general effort to identify security bugs as such. Obviously this one was known to be a security bug, but the general policy (see #1) is to avoid announcing it. #3: In any embargo situation, if you’re not on the distribution list, you don’t get notified. This is unavoidable. oss-security nominally handles everyone else, but it’s very spotty. Sometimes I wish there was a Linux kernel security advisory process, but this would need funding or a dedicated volunteer.
- rfoo 5y ago
  TBH the thing annoyed me most in this story is the "Someone had to start the disclosure process on linux-distros again and if they didn't no one would know"-part. There are certainly silent bug fixes where the author intentionally (or not) does not post to linux-distros or any other maillists even after stable release. It would take an hour to dig a good example tho. (Okay, maybe 10 minutes if I'm going to read Brad Spengler's rants) I guess a Linux kernel security advisory process is needed to fix this, but yeah :(
  - amluto 5y ago
    For what it’s worth, linux-distros has its own opinions that are not necessarily compatible with those of the upstream kernel.
- mjw1007 5y ago
  If only there was some kind of foundation with a revenue of $177 million last year which had an interest in Linux's success.
  - nisa 5y ago
    they are busy doing blockchain projects :)
- sirdarckcat 5y ago
  > Sometimes I wish there was a Linux kernel security advisory process, but this would need funding or a dedicated volunteer. This is already happening https://osv.dev/list?q=Kernel&affected_only=true&page=1&ecosystem=Linux https://osv.dev/list?q=Kernel&affected_only=true&page=1&ecos...
  - amluto 5y ago
    As far as I know, this doesn’t get information from upstream maintainers. For this to work well, I think we would want actual advisories generated around commit time, embargoed early notification, and a process for publication.

by rfoo 5y ago

amluto 5y ago

#1 is intentional, for better or for worse. It’s certainly well-intentioned too, although the intentions may be based on wrong assumptions. #2: upstream makes no general effort to identify security bugs as such. Obviously this one was known to be a security bug, but the general policy (see #1) is to avoid announcing it. #3: In any embargo situation, if you’re not on the distribution list, you don’t get notified. This is unavoidable. oss-security nominally handles everyone else, but it’s very spotty. Sometimes I wish there was a Linux kernel security advisory process, but this would need funding or a dedicated volunteer.

rfoo 5y ago
TBH the thing annoyed me most in this story is the "Someone had to start the disclosure process on linux-distros again and if they didn't no one would know"-part. There are certainly silent bug fixes where the author intentionally (or not) does not post to linux-distros or any other maillists even after stable release. It would take an hour to dig a good example tho. (Okay, maybe 10 minutes if I'm going to read Brad Spengler's rants) I guess a Linux kernel security advisory process is needed to fix this, but yeah :(
- amluto 5y ago
  For what it’s worth, linux-distros has its own opinions that are not necessarily compatible with those of the upstream kernel.
mjw1007 5y ago
If only there was some kind of foundation with a revenue of $177 million last year which had an interest in Linux's success.
- nisa 5y ago
  they are busy doing blockchain projects :)
sirdarckcat 5y ago
> Sometimes I wish there was a Linux kernel security advisory process, but this would need funding or a dedicated volunteer. This is already happening https://osv.dev/list?q=Kernel&affected_only=true&page=1&ecosystem=Linux https://osv.dev/list?q=Kernel&affected_only=true&page=1&ecos...
- amluto 5y ago
  As far as I know, this doesn’t get information from upstream maintainers. For this to work well, I think we would want actual advisories generated around commit time, embargoed early notification, and a process for publication.