3 ms·

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

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.

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.