Skip to content
Snippets Groups Projects
  1. Oct 30, 2023
  2. Nov 20, 2018
    • Will Deacon's avatar
      Documentation/security-bugs: Postpone fix publication in exceptional cases · 544b03da
      Will Deacon authored
      
      At the request of the reporter, the Linux kernel security team offers to
      postpone the publishing of a fix for up to 5 business days from the date
      of a report.
      
      While it is generally undesirable to keep a fix private after it has
      been developed, this short window is intended to allow distributions to
      package the fix into their kernel builds and permits early inclusion of
      the security team in the case of a co-ordinated disclosure with other
      parties. Unfortunately, discussions with major Linux distributions and
      cloud providers has revealed that 5 business days is not sufficient to
      achieve either of these two goals.
      
      As an example, cloud providers need to roll out KVM security fixes to a
      global fleet of hosts with sufficient early ramp-up and monitoring. An
      end-to-end timeline of less than two weeks dramatically cuts into the
      amount of early validation and increases the chance of guest-visible
      regressions.
      
      The consequence of this timeline mismatch is that security issues are
      commonly fixed without the involvement of the Linux kernel security team
      and are instead analysed and addressed by an ad-hoc group of developers
      across companies contributing to Linux. In some cases, mainline (and
      therefore the official stable kernels) can be left to languish for
      extended periods of time. This undermines the Linux kernel security
      process and puts upstream developers in a difficult position should they
      find themselves involved with an undisclosed security problem that they
      are unable to report due to restrictions from their employer.
      
      To accommodate the needs of these users of the Linux kernel and
      encourage them to engage with the Linux security team when security
      issues are first uncovered, extend the maximum period for which fixes
      may be delayed to 7 calendar days, or 14 calendar days in exceptional
      cases, where the logistics of QA and large scale rollouts specifically
      need to be accommodated. This brings parity with the linux-distros@
      maximum embargo period of 14 calendar days.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: Amit Shah <aams@amazon.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Co-developed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Co-developed-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      544b03da
    • Will Deacon's avatar
      Documentation: Use "while" instead of "whilst" · 806654a9
      Will Deacon authored
      
      Whilst making an unrelated change to some Documentation, Linus sayeth:
      
        | Afaik, even in Britain, "whilst" is unusual and considered more
        | formal, and "while" is the common word.
        |
        | [...]
        |
        | Can we just admit that we work with computers, and we don't need to
        | use þe eald Englisc spelling of words that most of the world never
        | uses?
      
      dictionary.com refers to the word as "Chiefly British", which is
      probably an undesirable attribute for technical documentation.
      
      Replace all occurrences under Documentation/ with "while".
      
      Cc: David Howells <dhowells@redhat.com>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Michael Halcrow <mhalcrow@google.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      806654a9
  3. Oct 23, 2018
  4. Mar 09, 2018
    • Dave Hansen's avatar
      docs: clarify security-bugs disclosure policy · 7f5d465f
      Dave Hansen authored
      
      I think we need to soften the language a bit.  It might scare folks
      off, especially the:
      
      	 We prefer to fully disclose the bug as soon as possible.
      
      which is not really the case.  Linus says:
      
      	It's not full disclosure, it's not coordinated disclosure,
      	and it's not "no disclosure".  It's more like just "timely
      	open fixes".
      
      I changed a bit of the wording in here, but mostly to remove the word
      "disclosure" since it seems to mean very specific things to people
      that we do not mean here.
      
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      7f5d465f
  5. Mar 07, 2017
  6. Oct 24, 2016
  7. Sep 21, 2016
  8. Mar 31, 2011
  9. Apr 16, 2005
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4
Loading