3 ms·

> The way I look at it is that if ext* support is left in the system, it still needs tested thoroughly. Could you explain why? Especially 'thoroughly'. > It f

by DCKing 12y ago

> The way I look at it is that if ext* support is left in the system, it still needs tested thoroughly. Could you explain why? Especially 'thoroughly'. > It feels that mentioning security as part of the reason was just trying to justify the decision after the fact. No doubt. The actual reason is "we don't want to maintain this piece of code anymore because of the added complexity". Security concerns are merely a consequence of this added complexity. That does not mean it is false to say it, though.

lotsofmangos 12y ago
Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered. edit- the way I look at code security is that trying to write good code in the first place is not as important as the testing regime to find bad code, so while there is a risk of introducing new bugs by supporting ext* in the files app, this is counterbalanced by the risk that the underlying ext* implementation will not be included in as many tests.
- DCKing 12y ago
  > Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered. If you want to mount an external ext* partition yourself in ChromeOS from now on, you'll have to do some manual work going down to Linux using a terminal or Crouton. If there's an exploit in any of that, it will also affect millions of other Linux computers around the world as ChromeOS is no different from any other Linux distro with respect to ext* anymore (just Linux + ext kernel modules + e2fsprogs). Google will not feel obliged to cover that use case in their tests, and rightly so I think. In fact, they have described their "support" of ext* as accidental in the original thread, so it doesn't appear they ever tested it in the first place.
  - lotsofmangos 12y ago
    That sounds like the same approach that everyone used with openSSL. The fact that code is open source is not a sane reason not to test it.
    - DCKing 12y ago
      I sympathize with the general sentiment, but it misses the point. Linux + ext kernel modules + e2fsprogs is tested daily by developers of many Linux distributions. There's really no problem with verifying that some module works. Furthermore, Google tests this system implicitly by haveing ChromeOS use ext4 as its root file system. So everyone is right to be confident it works correctly. However, testing whether or not something works is totally different from testing whether it is secure. Many people testing whether OpenSSL works correctly (which happens every single day) would not have shown Heartbleed at all.

by DCKing 12y ago

lotsofmangos 12y ago

Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered. edit- the way I look at code security is that trying to write good code in the first place is not as important as the testing regime to find bad code, so while there is a risk of introducing new bugs by supporting ext* in the files app, this is counterbalanced by the risk that the underlying ext* implementation will not be included in as many tests.

DCKing 12y ago
> Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered. If you want to mount an external ext* partition yourself in ChromeOS from now on, you'll have to do some manual work going down to Linux using a terminal or Crouton. If there's an exploit in any of that, it will also affect millions of other Linux computers around the world as ChromeOS is no different from any other Linux distro with respect to ext* anymore (just Linux + ext kernel modules + e2fsprogs). Google will not feel obliged to cover that use case in their tests, and rightly so I think. In fact, they have described their "support" of ext* as accidental in the original thread, so it doesn't appear they ever tested it in the first place.
- lotsofmangos 12y ago
  That sounds like the same approach that everyone used with openSSL. The fact that code is open source is not a sane reason not to test it.
  - DCKing 12y ago
    I sympathize with the general sentiment, but it misses the point. Linux + ext kernel modules + e2fsprogs is tested daily by developers of many Linux distributions. There's really no problem with verifying that some module works. Furthermore, Google tests this system implicitly by haveing ChromeOS use ext4 as its root file system. So everyone is right to be confident it works correctly. However, testing whether or not something works is totally different from testing whether it is secure. Many people testing whether OpenSSL works correctly (which happens every single day) would not have shown Heartbleed at all.