5 ms·

It sounds like a really bad idea to have all software "components" be resolved, downloaded, and executed from over the internet. Seems like a supply chain/water

by Ruq 4y ago

It sounds like a really bad idea to have all software "components" be resolved, downloaded, and executed from over the internet. Seems like a supply chain/waterhole attack just waiting to happen. Not to mention it would seem to sign away the devices ability to act autonomously or offline. Of course, with my views of Google, it seems very like them to design everything to constantly rely on them to even function. Correct me if I'm wrong on any of this.

katbyte 4y ago
I would tend to agree, unless pinning is enforced/the default.
- turminal 4y ago
  I think the idea is "ensuring software is always up to date", so no pinning by default.
  - metadat 4y ago
    Until they drop support for your hardware... Then what happens?
    - ketralnis 4y ago
      You have to chuck it in the bin and buy a new one, obviously. That's the state of the startphone world today, if you want to keep up on security updates
      - myko 4y ago
        This is lamentable and I'd love to see longer periods of support for older devices, but I'm not sure what the ideal state is - beyond being able to install your own OS on your device, which will still require some level of support from someone. What's reasonable - 5 years of support? 10?
  - dhodell 4y ago
    These things work in tandem: the base system is pinned, but can also be easily updated with an OTA. Packages existing outside that set are resolved on-demand, and are thus updated when components in a package are run after a new version is published to the package repository.
  - katbyte 4y ago
    until randomly without warning the latest version is broken, removes something, deprecates something, or is incompatible with something else. "always up to date" is something that sounds great but in practice has many many pitfalls.
fartcannon 4y ago
They're claiming its about trusting the code you run. Google, you're the source of the code I don't trust.
londons_explore 4y ago
I like the idea of it being possible. Just because it's a feature doesn't mean you have to use it. For one thing, I assume such a system would have the ability to pin certain versions/hashes. If I (the user) can pin a set of hashes that are allowed to run, then I don't care where the actual resources are downloaded from. Alternatively, if I can give a certificate I trust of someone else to give a 'realtime' list, that would also satisfy my needs.
- wittrock 4y ago
  Hi there, I work on Fuchsia, specifically on our Software Delivery system [1]. You hit on exactly the right point: it's _possible_ to download and run software on demand, but it's also possible (and recommended) for products to turn off that capability if it's not useful or valuable for their use case. We pin packages for the base system itself, as well as lots of configurations of products. The ability to run code on demand is really valuable for our development flows and quick prototyping: built a new test or experiment? No need to update your device, just try to run it, and it runs! [1]: https://fuchsia.dev/fuchsia-src/get-started/learn/intro/packages?hl=en https://fuchsia.dev/fuchsia-src/get-started/learn/intro/pack...
  - erickt 4y ago
    I also work on Fuchsia’s Software delivery team. For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from: * a hardware key (on hardware that supports it), which checks the signature of * the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then contains a hash of the zircon kernel, and the merkle root for the user space system image blob. * we boot up zircon, which eventually starts up blobfs, our content addressed file system. It then reads the system image from blobfs, and launches Component Manager and Package Cache (which implements a package filesystem on top of blobs). * package cache gets launched with the system image merkle from vbmeta, which allows us to know which packages are part of the base package set. * base packages are then launched upon demand. This establishes a direct line of trust from the hardware key to the base packages. For over the air updates and ephemerally resolved packages, we use The Update Framework [2] and Omaha [3] for our package repositories. Each entry contains the merkle root for the package metadata, which in turn bakes in the merkle roots for each blob in the packages. We bake in the public keys for TUF and Omaha into our system image. This allows us to indirectly verify from hardware up that we are fetching the correct software. [1]: https://fuchsia.dev/fuchsia-src/concepts/security/verified_execution?hl=en https://fuchsia.dev/fuchsia-src/concepts/security/verified_e... [2]: https://theupdateframework.io/ https://theupdateframework.io/ [3]: https://chromium.googlesource.com/chromium/src.git/+/master/docs/updater/protocol_3_1.md https://chromium.googlesource.com/chromium/src.git/+/master/...
cptskippy 4y ago
This sounds like exactly the kind of enterprise OS running on Servers that Google wants for itself. Not something for consumer devices.
- guyzero 4y ago
  You'll be surprised of the first commercial deployment of Fuchsia then: https://www.theverge.com/2021/8/18/22630245/google-fuchsia-os-nest-hub-rollout-release-date https://www.theverge.com/2021/8/18/22630245/google-fuchsia-o...
  - cptskippy 4y ago
    I guess that makes sense. Those screens are black boxes as far as the user is concerned and highly dependent on the cloud to even function. I guess I was thinking more Laptops and Phones.
deleted 4y ago
[deleted]

by Ruq 4y ago

katbyte 4y ago

I would tend to agree, unless pinning is enforced/the default.

turminal 4y ago
I think the idea is "ensuring software is always up to date", so no pinning by default.
- metadat 4y ago
  Until they drop support for your hardware... Then what happens?
  - ketralnis 4y ago
    You have to chuck it in the bin and buy a new one, obviously. That's the state of the startphone world today, if you want to keep up on security updates
    - myko 4y ago
      This is lamentable and I'd love to see longer periods of support for older devices, but I'm not sure what the ideal state is - beyond being able to install your own OS on your device, which will still require some level of support from someone. What's reasonable - 5 years of support? 10?
- dhodell 4y ago
  These things work in tandem: the base system is pinned, but can also be easily updated with an OTA. Packages existing outside that set are resolved on-demand, and are thus updated when components in a package are run after a new version is published to the package repository.
- katbyte 4y ago
  until randomly without warning the latest version is broken, removes something, deprecates something, or is incompatible with something else. "always up to date" is something that sounds great but in practice has many many pitfalls.

fartcannon 4y ago

They're claiming its about trusting the code you run. Google, you're the source of the code I don't trust.

londons_explore 4y ago

I like the idea of it being possible. Just because it's a feature doesn't mean you have to use it. For one thing, I assume such a system would have the ability to pin certain versions/hashes. If I (the user) can pin a set of hashes that are allowed to run, then I don't care where the actual resources are downloaded from. Alternatively, if I can give a certificate I trust of someone else to give a 'realtime' list, that would also satisfy my needs.

wittrock 4y ago
Hi there, I work on Fuchsia, specifically on our Software Delivery system [1]. You hit on exactly the right point: it's _possible_ to download and run software on demand, but it's also possible (and recommended) for products to turn off that capability if it's not useful or valuable for their use case. We pin packages for the base system itself, as well as lots of configurations of products. The ability to run code on demand is really valuable for our development flows and quick prototyping: built a new test or experiment? No need to update your device, just try to run it, and it runs! [1]: https://fuchsia.dev/fuchsia-src/get-started/learn/intro/packages?hl=en https://fuchsia.dev/fuchsia-src/get-started/learn/intro/pack...
- erickt 4y ago
  I also work on Fuchsia’s Software delivery team. For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from: * a hardware key (on hardware that supports it), which checks the signature of * the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then contains a hash of the zircon kernel, and the merkle root for the user space system image blob. * we boot up zircon, which eventually starts up blobfs, our content addressed file system. It then reads the system image from blobfs, and launches Component Manager and Package Cache (which implements a package filesystem on top of blobs). * package cache gets launched with the system image merkle from vbmeta, which allows us to know which packages are part of the base package set. * base packages are then launched upon demand. This establishes a direct line of trust from the hardware key to the base packages. For over the air updates and ephemerally resolved packages, we use The Update Framework [2] and Omaha [3] for our package repositories. Each entry contains the merkle root for the package metadata, which in turn bakes in the merkle roots for each blob in the packages. We bake in the public keys for TUF and Omaha into our system image. This allows us to indirectly verify from hardware up that we are fetching the correct software. [1]: https://fuchsia.dev/fuchsia-src/concepts/security/verified_execution?hl=en https://fuchsia.dev/fuchsia-src/concepts/security/verified_e... [2]: https://theupdateframework.io/ https://theupdateframework.io/ [3]: https://chromium.googlesource.com/chromium/src.git/+/master/docs/updater/protocol_3_1.md https://chromium.googlesource.com/chromium/src.git/+/master/...

cptskippy 4y ago

This sounds like exactly the kind of enterprise OS running on Servers that Google wants for itself. Not something for consumer devices.

guyzero 4y ago
You'll be surprised of the first commercial deployment of Fuchsia then: https://www.theverge.com/2021/8/18/22630245/google-fuchsia-os-nest-hub-rollout-release-date https://www.theverge.com/2021/8/18/22630245/google-fuchsia-o...
- cptskippy 4y ago
  I guess that makes sense. Those screens are black boxes as far as the user is concerned and highly dependent on the cloud to even function. I guess I was thinking more Laptops and Phones.

deleted 4y ago

[deleted]