5 ms·

A lot of macOS is open source. https://news.ycombinator.com/item?id=15251891 https://news.ycombinator.com/item?id=15251891 https://developer.apple.com/opensou

A lot of macOS is open source. https://news.ycombinator.com/item?id=15251891 https://news.ycombinator.com/item?id=15251891 https://developer.apple.com/opensource/ https://developer.apple.com/opensource/

msla 9y ago
Unless I can build and install a completely custom version, it isn't open enough to be safe.
- astrodust 9y ago
  Can't trust the OS without all the code. Can't trust the code if you can't trust the compiler. Can't trust the compiler if you can't trust the CPU. Can't trust the CPU if you can't trust the microcode. Can't trust the microcode unless you've visually inspected the die. You can't win. Make compromises that are reasonable.
  - oliwarner 9y ago
    > Make compromises that are reasonable. When it's so easy to use a community-vetted Linux distribution, I think "reasonable" gets shunted down a layer. It's not all or nothing. Every reasonable step counts.
    - abiox 9y ago
      > community-vetted i wonder if this sort of confidence makes you less-safe. something like this should've prevented heartbleed, in theory, right?
      - oliwarner 9y ago
        It's not confidence that I'm secure, it's a belief that this software development process makes me more secure. You and your friend down there seemingly have more faith that a closed source process, what, would have identified this bug before it was deployed? Why? That it would have been found by good actors first? Why? That it would have been fixed promptly? Why? Announced with disclosure of its existence and ramifications? Why? It's not a money question for this stuff either. There are hundreds if not thousands of paid engineers for known good-actors all working to break and responsibly disclose security issues in the same software stack I use. The only thing you know about the comings and goings of closed source software is when public disclosure happens (and it's later fixed). Why would I be more confident in that process? It's not good enough.
    - scarface74 9y ago
      "Community-vetting" didn't stop the HeartBleed bug to linger for over a year.
      - msla 9y ago
        And we have no idea how many bugs worse than HeartBleed haven't been found yet in closed-source software.
        astrodust 9y ago
        It depends on the development process. Some companies aggressively re-visit older code, others never look at it. Open-source is not inherently better or worse, it's all a matter of motivation on the part of the developers.
  - dredmorbius 9y ago
    Cross-compiling and multi-device compiles are a thing.
    - abiox 9y ago
      i feel like this is just shuffling concerns rather than addressing them, but i'm open to being shown otherwise.
      - dredmorbius 9y ago
        Suppose you suspect compiler A or CPU X. Recompile on compilers B and C and compare results. Or on CPUs Y and Z. In reality, there will almost certainly be differences (different compiling algos, different CPU instruction sets), but if you can pinpoint behavioural distinctions or encoding distinctions which are not explained by known compile or instruction-set distinctions, well, you've got something interesting to explore. The point being that you don't have to descend the entire stack of turtles. Just compare different stacks of turtles.
        astrodust 9y ago
        It's going to be really hard to compare binary A vs. binary B and determine functional differences. clang and gcc emit entirely different machine code, but they do their best to be functionally identical, at least as far as their respective specs are concerned.
- egwynn 9y ago
  You get my upvote, because I respect your perspective and I agree in principle. But at its logical conclusion, this idea puts up some serious practical barriers. Even if you only use an OS that you’ve personally audited, and even if you’ve gotten past the potential Thompsonian compiler issues, you’re still left with a minefield of possibly-adversarial pieces of software that might interfere with your computing experience. Have you audited your BIOS/UEFI firmware [0]? Your CPU’s microcode [1]? Your WiFi/Bluetooth adapter’s firmware [2]? Your HDD controller’s firmware [3]? I acknowledge that I’m advancing something of a “slippery slope” argument here, but I still care about the question. Where do you draw the line? Obviously being able to audit all of it yourself perfectly would be awesome. But to me that just seems impossible. So how much is enough? EDIT: beaten by astrodust! [0] https://www.pcworld.com/article/2948092/security/hacking-teams-malware-uses-uefi-rootkit-to-survive-os-reinstalls.html https://www.pcworld.com/article/2948092/security/hacking-tea... [1] https://www.dcddcc.com/docs/2014_paper_microcode.pdf https://www.dcddcc.com/docs/2014_paper_microcode.pdf [2] https://blog.exodusintel.com/2017/07/26/broadpwn/ https://blog.exodusintel.com/2017/07/26/broadpwn/ [3] http://spritesmods.com/?art=hddhack&page=1 http://spritesmods.com/?art=hddhack&page=1
- YouKnowBetter 9y ago
  You compile (After reading and understanding the source) of the firmware used on your machine? You take your time to read & understand the millions lines of code of all libraries needed? You know & trust your compiler? As much as I appriciate the sentiment, I have to admit I personally gave up trusting OSS for the soul reason that I / someone might be able to read and understand it.

msla 9y ago

Unless I can build and install a completely custom version, it isn't open enough to be safe.

astrodust 9y ago
Can't trust the OS without all the code. Can't trust the code if you can't trust the compiler. Can't trust the compiler if you can't trust the CPU. Can't trust the CPU if you can't trust the microcode. Can't trust the microcode unless you've visually inspected the die. You can't win. Make compromises that are reasonable.
- oliwarner 9y ago
  > Make compromises that are reasonable. When it's so easy to use a community-vetted Linux distribution, I think "reasonable" gets shunted down a layer. It's not all or nothing. Every reasonable step counts.
  - abiox 9y ago
    > community-vetted i wonder if this sort of confidence makes you less-safe. something like this should've prevented heartbleed, in theory, right?
    - oliwarner 9y ago
      It's not confidence that I'm secure, it's a belief that this software development process makes me more secure. You and your friend down there seemingly have more faith that a closed source process, what, would have identified this bug before it was deployed? Why? That it would have been found by good actors first? Why? That it would have been fixed promptly? Why? Announced with disclosure of its existence and ramifications? Why? It's not a money question for this stuff either. There are hundreds if not thousands of paid engineers for known good-actors all working to break and responsibly disclose security issues in the same software stack I use. The only thing you know about the comings and goings of closed source software is when public disclosure happens (and it's later fixed). Why would I be more confident in that process? It's not good enough.
  - scarface74 9y ago
    "Community-vetting" didn't stop the HeartBleed bug to linger for over a year.
    - msla 9y ago
      And we have no idea how many bugs worse than HeartBleed haven't been found yet in closed-source software.
      - astrodust 9y ago
        It depends on the development process. Some companies aggressively re-visit older code, others never look at it. Open-source is not inherently better or worse, it's all a matter of motivation on the part of the developers.
- dredmorbius 9y ago
  Cross-compiling and multi-device compiles are a thing.
  - abiox 9y ago
    i feel like this is just shuffling concerns rather than addressing them, but i'm open to being shown otherwise.
    - dredmorbius 9y ago
      Suppose you suspect compiler A or CPU X. Recompile on compilers B and C and compare results. Or on CPUs Y and Z. In reality, there will almost certainly be differences (different compiling algos, different CPU instruction sets), but if you can pinpoint behavioural distinctions or encoding distinctions which are not explained by known compile or instruction-set distinctions, well, you've got something interesting to explore. The point being that you don't have to descend the entire stack of turtles. Just compare different stacks of turtles.
      - astrodust 9y ago
        It's going to be really hard to compare binary A vs. binary B and determine functional differences. clang and gcc emit entirely different machine code, but they do their best to be functionally identical, at least as far as their respective specs are concerned.
egwynn 9y ago
You get my upvote, because I respect your perspective and I agree in principle. But at its logical conclusion, this idea puts up some serious practical barriers. Even if you only use an OS that you’ve personally audited, and even if you’ve gotten past the potential Thompsonian compiler issues, you’re still left with a minefield of possibly-adversarial pieces of software that might interfere with your computing experience. Have you audited your BIOS/UEFI firmware [0]? Your CPU’s microcode [1]? Your WiFi/Bluetooth adapter’s firmware [2]? Your HDD controller’s firmware [3]? I acknowledge that I’m advancing something of a “slippery slope” argument here, but I still care about the question. Where do you draw the line? Obviously being able to audit all of it yourself perfectly would be awesome. But to me that just seems impossible. So how much is enough? EDIT: beaten by astrodust! [0] https://www.pcworld.com/article/2948092/security/hacking-teams-malware-uses-uefi-rootkit-to-survive-os-reinstalls.html https://www.pcworld.com/article/2948092/security/hacking-tea... [1] https://www.dcddcc.com/docs/2014_paper_microcode.pdf https://www.dcddcc.com/docs/2014_paper_microcode.pdf [2] https://blog.exodusintel.com/2017/07/26/broadpwn/ https://blog.exodusintel.com/2017/07/26/broadpwn/ [3] http://spritesmods.com/?art=hddhack&page=1 http://spritesmods.com/?art=hddhack&page=1
YouKnowBetter 9y ago
You compile (After reading and understanding the source) of the firmware used on your machine? You take your time to read & understand the millions lines of code of all libraries needed? You know & trust your compiler? As much as I appriciate the sentiment, I have to admit I personally gave up trusting OSS for the soul reason that I / someone might be able to read and understand it.