The Windows client caches the current version for a while, so may not yet have v1.32.3 available on your device.
In that case, you can still pull the latest release from http://pkgs.tailscale.com/stable.
The biggest difference for me is that in-toto allows you to define any set of upstream metadata requirements, in a very open format, and Binary Authorization has a set of centrally defined requirements, that teams tend to implement in tranches, to meet minimum requirements. It may sound better to have a freeform format, but in practice, I've found that it makes it harder for people to know what they should actually do.
In Binary Authorization for Borg, services still define service-specific policies, but pick from a previously defined set of potential requirements. See the section on service-specific policies: https://cloud.google.com/security/binary-authorization-for-b...
You can more easily compare Grafeas and Kritis (OSS projects Google developed, which are similar to GCR Vulnerability Scanning and Binary Authorization for GKE), to in-toto. In fact, I gave a talk covering some of the options for this here: https://youtu.be/uDWXKKEO8NU?t=1314
Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.
I think that's right. I would strengthen that statement slightly - it's about ensuring that no actor - whether an insider, or someone who has stolen their credentials, or otherwise compromised them - can perform an action that single handedly accesses user data, without it being known to another actor - via access logs, via approvals, etc.
In terms of the upstream introduction of a new vulnerability, Binary Authorization for Borg can only verify that the code was in fact merged. See the section on third party code, "When importing changes from third party or open source code, we verify that the change is appropriate (for example, the latest version)."
Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.
I think 'garbage' is a strong word, but I believe what the original poster is trying to say is that there are a lot of binaries, packages, and libraries that most organizations will consume from upstream, and not verify directly. This requires either trust on a third party (often many third parties - in the case of open source), or more intense validation of those components and any changes to those components.
Binary Authorization for Borg performs verification for pieces that come out of Google's CI/CD pipeline. For third party code, see in the doc, "When importing changes from third party or open source code, we verify that the change is appropriate (for example, the latest version)."
Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.
Agreed with this statement.
It's a best practice generally to verify all software updates originate from a particular source before applying them in your environment. Most over the wire updates do this.
What's different with Binary Authorization for Borg is that within Google, that last verification step means more than just "came from Google", but "came from Google and went through all previous necessary checks", because of the way the CI/CD system works together.
Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.
Hi,
We're the team working on Google's experimental encrypted BigQuery client, also mentioned in the article. It's open-sourced and available on github:
https://github.com/google/encrypted-bigquery-client
Happy to answer any questions or chat about cool uses of PHE!