5 ms·

I think lots of people (particularly security people) tend to fundamentally misunderstand how the Linux community works. It's not a single organization calling

I think lots of people (particularly security people) tend to fundamentally misunderstand how the Linux community works. It's not a single organization calling the shots where they can have a meeting behind closed doors about the vulnerability and internally incubate a patchset. That's simply not how Linux development works. Linux is a loosely organized community of developers who collaborate in public. They don't have any ubiquitous communication channels established other than mailing lists. If you attempted to establish a private security mailing list, the list of people who get to go on it is (1) hard to define (2) very large and (3) frequently changing. The affected subsystems have lots of disparate maintainers and interested parties who need to get their eyes on any patches that go into them. It might not be ideal from a security person's perspective but from everyone else's perspective this model has been the driving factor behind the most successful collaborative project of all time.

masklinn 9y ago
> It's not a single organization calling the shots where they can have a meeting behind closed doors about the vulnerability and internally incubate a patchset. That's simply not how Linux development works. Bullshit. Ultimately, Linus decides what does or does not go in, assisted by the subsystem maintainers he picked. If they wanted to have closed doors meeting, they could, and would. FreeBSD and the like have no more and no less "single organisation calling the shots", the only difference is that they're not a human clusterfuck. > It might not be ideal from a security person's perspective but from everyone else's perspective this model has been the driving factor behind the most successful collaborative project of all time. That just means Linux at large will ultimately get ignored for anything security-sensitive, and only specific distributions will be contacted.
- Sir_Cmpwn 9y ago
  https://en.wikipedia.org/wiki/FreeBSD#Development https://en.wikipedia.org/wiki/FreeBSD#Development
  - masklinn 9y ago
    Yeah so? > The FreeBSD Project is run by around 500 committers, or developers who have commit access to the master source code repositories and can develop, debug or enhance any part of the system. I doubt there are 500 people with push access to the main Linux repository. Again, the FreeBSD folks just have their shit together.
    - Sir_Cmpwn 9y ago
      I was pointing out the existence of a governing body and a core team on FreeBSD, for which there is no analogue on Linux. There is no "the main Linux repository".
      - masklinn 9y ago
        > there is no analogue on Linux. There is no "the main Linux repository". Of course there is. Linus decides what goes into the mainline kernel, his repository is literally called "Linux kernel source tree"[0], with the stable "archive" being sensibly called "Linux kernel stable tree"[1], and Linux's analogue to the freebsd core team is de-facto Linus and his trusted maintainers, the people from whom he reviews and pulls commits. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/about/ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
        Sir_Cmpwn 9y ago
        You don't understand. This is a list of people who have ownership over some part of Linux: https://github.com/torvalds/linux/blob/master/MAINTAINERS https://github.com/torvalds/linux/blob/master/MAINTAINERS Linus might have the "final say" but all of the work and knowledge is encapsulated in these people and they are generally given the autonomy to organize and maintain their subsystems as they see fit. As for Linus's tree, it's probably the most Linux Linux that's out there, but it's hardly the only one. Hardly anyone actually runs Linux from Linus's tree. Most distros maintain their own trees with their own patchsets.
gregkh 9y ago
Linux has a security team/list that does handle disclosures and fixing of reported problems. It usually does this by just dragging in the responsible parties, but many times it just fixes the problems themselves and submits the patches to the proper part of the kernel. For details on how this works, please see the kernel documentation itself: https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html https://www.kernel.org/doc/html/latest/admin-guide/security-...
- Sir_Cmpwn 9y ago
  Thanks for clarifying, Greg. >It usually does this by just dragging in the responsible parties, but many times it just fixes the problems themselves and submits the patches to the proper part of the kernel. I think this is the key - once the patches are submitted they go through the normal workflow and aren't any different from a typical patch, right?
  - gregkh 9y ago
    Yes, once the patches are generated, they get submitted just like any other kernel change, sent to the responsible subsystem and maintainer for inclusion like any other kernel change.
    - Sir_Cmpwn 9y ago
      I think this is where the problems becomes apparent. The change then has to go through the subsystem's patch flow (in public) then into the merge window (in public) and sit in the release pipeline (in public) until the window closes and all of the rc's are through. Personally I don't think this is a huge deal, but it's where the disconnect between the security person's ideal worldview and the reality of how Linux is built colllide.
      - qznc 9y ago
        Distros could speed this up. If the security team notifies RedHat, Ubuntu, etc and they can apply the patch for their kernels immediately. They probably need to backport it anyways, because no distro (well, maybe Arch?) just uses the latest Linux release.
jlgaddis 9y ago
> If you attempted to establish a private security mailing list, ... Like the linux-distros [0] list? Or just the kernel developers? (Note that both Linus and Greg are on this list.) [0]: http://oss-security.openwall.org/wiki/mailing-lists/distros http://oss-security.openwall.org/wiki/mailing-lists/distros
- Sir_Cmpwn 9y ago
  Linux distros are different from Linux the kernel, and handle security differently. Greg has some good comments in this thread for how the kernel does it.

masklinn 9y ago

> It's not a single organization calling the shots where they can have a meeting behind closed doors about the vulnerability and internally incubate a patchset. That's simply not how Linux development works. Bullshit. Ultimately, Linus decides what does or does not go in, assisted by the subsystem maintainers he picked. If they wanted to have closed doors meeting, they could, and would. FreeBSD and the like have no more and no less "single organisation calling the shots", the only difference is that they're not a human clusterfuck. > It might not be ideal from a security person's perspective but from everyone else's perspective this model has been the driving factor behind the most successful collaborative project of all time. That just means Linux at large will ultimately get ignored for anything security-sensitive, and only specific distributions will be contacted.

Sir_Cmpwn 9y ago
https://en.wikipedia.org/wiki/FreeBSD#Development https://en.wikipedia.org/wiki/FreeBSD#Development
- masklinn 9y ago
  Yeah so? > The FreeBSD Project is run by around 500 committers, or developers who have commit access to the master source code repositories and can develop, debug or enhance any part of the system. I doubt there are 500 people with push access to the main Linux repository. Again, the FreeBSD folks just have their shit together.
  - Sir_Cmpwn 9y ago
    I was pointing out the existence of a governing body and a core team on FreeBSD, for which there is no analogue on Linux. There is no "the main Linux repository".
    - masklinn 9y ago
      > there is no analogue on Linux. There is no "the main Linux repository". Of course there is. Linus decides what goes into the mainline kernel, his repository is literally called "Linux kernel source tree"[0], with the stable "archive" being sensibly called "Linux kernel stable tree"[1], and Linux's analogue to the freebsd core team is de-facto Linus and his trusted maintainers, the people from whom he reviews and pulls commits. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/about/ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
      - Sir_Cmpwn 9y ago
        You don't understand. This is a list of people who have ownership over some part of Linux: https://github.com/torvalds/linux/blob/master/MAINTAINERS https://github.com/torvalds/linux/blob/master/MAINTAINERS Linus might have the "final say" but all of the work and knowledge is encapsulated in these people and they are generally given the autonomy to organize and maintain their subsystems as they see fit. As for Linus's tree, it's probably the most Linux Linux that's out there, but it's hardly the only one. Hardly anyone actually runs Linux from Linus's tree. Most distros maintain their own trees with their own patchsets.

gregkh 9y ago

Linux has a security team/list that does handle disclosures and fixing of reported problems. It usually does this by just dragging in the responsible parties, but many times it just fixes the problems themselves and submits the patches to the proper part of the kernel. For details on how this works, please see the kernel documentation itself: https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html https://www.kernel.org/doc/html/latest/admin-guide/security-...

Sir_Cmpwn 9y ago
Thanks for clarifying, Greg. >It usually does this by just dragging in the responsible parties, but many times it just fixes the problems themselves and submits the patches to the proper part of the kernel. I think this is the key - once the patches are submitted they go through the normal workflow and aren't any different from a typical patch, right?
- gregkh 9y ago
  Yes, once the patches are generated, they get submitted just like any other kernel change, sent to the responsible subsystem and maintainer for inclusion like any other kernel change.
  - Sir_Cmpwn 9y ago
    I think this is where the problems becomes apparent. The change then has to go through the subsystem's patch flow (in public) then into the merge window (in public) and sit in the release pipeline (in public) until the window closes and all of the rc's are through. Personally I don't think this is a huge deal, but it's where the disconnect between the security person's ideal worldview and the reality of how Linux is built colllide.
    - qznc 9y ago
      Distros could speed this up. If the security team notifies RedHat, Ubuntu, etc and they can apply the patch for their kernels immediately. They probably need to backport it anyways, because no distro (well, maybe Arch?) just uses the latest Linux release.

jlgaddis 9y ago

> If you attempted to establish a private security mailing list, ... Like the linux-distros [0] list? Or just the kernel developers? (Note that both Linus and Greg are on this list.) [0]: http://oss-security.openwall.org/wiki/mailing-lists/distros http://oss-security.openwall.org/wiki/mailing-lists/distros

Sir_Cmpwn 9y ago
Linux distros are different from Linux the kernel, and handle security differently. Greg has some good comments in this thread for how the kernel does it.