antoncohen

But when joining a Zoom call from your phone you dial a number, then enter the meeting ID. The meeting ID has the same number of digits as a US phone number, but it isn't the number you dial. The calendar invites generated by Zoom format the number + meeting ID in such as way that a user can tap them and it will dial the number and enter the meeting ID.

Basically, in both cases (computer/app or dial-in), increasing the number of digits of the meeting ID has very little impact on the users. Forcing a user to enter a password after joining (which is just more digits) does impact the user.

> The two bugs, Wardle said, can be launched by a local attacker — that’s where someone has physical control of a vulnerable computer.

TechCrunch got this wrong. "Local" means local privilege escalation, as opposed to "remote" code execution. They do not require physical access.

That being said, local privilege escalation on a single user computer where that user is an admin (most Macs), isn't a massive problem in my mind. It would allow malware, once run by the user, to bypass security prompts usually required to elevate access.

The mechanism of rsync + hardlinks is similar to BackupPC[1][2], which is an 18 year old open source backup tool, written in Perl, with a web UI. It supports backing up Mac, Windows, and Unix-like OSs, and is primarily for centrally backing up multiple computers. BackupPC's UI is obviously not as slick as this, but it does allow restoring individual files from a given date. If I remember correctly from 10+ year ago, their tar over SSH transport option performed better than rsync when used on a fast network.

[1] https://backuppc.github.io/backuppc/

[2] https://en.wikipedia.org/wiki/BackupPC

The mention of the shadow file is in the README:

> S-Cache is an SUID-root executable that works by storing the secret in a file that is owned by root and only readable by root. Its security is thus comparable to the security of shadow passwords.

That still comes down to when they are considered "aware". If I emailed GitHub and told them the "microsoft" org was run by people in Iran, would they then be "aware" and need to shutdown the "microsoft" org? If you consider automated flagging to be a tip-off that needs to be investigated, then you aren't "aware" until it is investigated.

I don't think 100 million repos matters. What matters is how many automated tip-offs they need to investigate. It would have taken two minutes of investigation to find out this repo wasn't from a sanctioned country. If it takes two minutes to review a case, a team of five people could review over a thousand cases in an eight hour day. I work for a tech company that has a team of people that reviews uploaded content for copyright violations, it can be done.

Remember that the sanctions are for commercial use, primarily paid accounts. These sanction violation aren't happening at the rate of something like YouTube copyright violations. I wouldn't be surprised if it was less than ten a day.

Does the law actually require a fully automated means of detection? For example to "nuke first" means you need to know that sanctions apply. If the law doesn't require it to be fully automated, "know that sanctions apply" could involve a human doing verification.

What frustrates me about these kind of things is how impersonal they are. How many orgs/users does GitHub sanction a day? Too many for it to be able to email the users and ask clarifying questions? Or even have a human dig in and double check what the algorithm says.

Basic human interaction would seemingly solve 99% of false account lockouts and takedowns. Even basic heuristics like this org has a repo with 11,000 stars, it isn't a new user that just signed up yesterday, we need to look into this deeper.

This is correct. "All rights reserved" was a way of claiming copyright, similar to the © symbol. Open source non-public domain code still has a copyright, it is just licensed for use under an open source license.

https://en.wikipedia.org/wiki/All_rights_reserved

That's strange, because the closest company to Google scale is Facebook, and they actually use Chef in production[1][2][3] on hundreds of thousands of servers.

[1] https://www.chef.io/customers/facebook/

[2] https://engineering.fb.com/core-data/facebook-configuration-...

[3] https://github.com/facebook/chef-cookbooks/

I won't talk much about FAANG scale, because that is hyper specialized.

A small startup shouldn't use any configuration management (assuming configuration management means software like Puppet, Chef, Salt, and Ansible). That is because small startups shouldn't be running anything on VMs (or bare metal). There are so many fully managed solutions out there. There is no reason to be running on VM, SSHing to servers, etc. App Engine, Heroku, GKE, Cloud Run, whatever.

Once you get to the point where you need to run VMs (or bare metal), there are many options. A lot of systems are going to a more image + container based solution. Think something like Container-Optimized OS[1] or Bottlerocket[2], where most of the file system is read-only, it is updated by swapping images (no package updates), and everything runs in containers.

If you are actually interested in config management, I'll give my opinions, and a bit of history. I've used all four of the current major config management systems (Puppet, Chef, Salt, and Ansible).

Puppet was the first of the bunch, it had its issues, but it was better than previous config managements systems. Twitter was one of the first big tech companies to use Puppet, and AFAIK they still do.

Chef was next, it was created by people to did Puppet consulting for a living. It follows a very similar model to Puppet, and solves most of the problems with Puppet, while introducing some problems of its own (mainly complexity in getting started). In my opinion Chef is a clear win over Puppet, and I don't think there is a good reason to pick Puppet anymore. One of the biggest advantages is that the config language is an actual programming language (Ruby). All the other systems started with language that was missing things like loops, and they have slowly grafted on programming language features. It is so much nicer to use an actual programming language. Facebook is a huge Chef user.

Salt was next. It was created by someone who wanted to run commands on a bunch of servers. It grew into a configuration management system. The underlying architecture of Salt is very nice, it is basically a bunch of nodes communicating over a message bus. Salt has different "renderers"[3], which are the language you write the config in, including ones that use a real programming language (Python). I'll back to Salt in a minute.

Ansible... it is very popular. This is going to sound harsh, but I'm just going to say it. I think is it popular with people who don't know how to use configuration management systems. You know how the Flask framework started as an April Fool's joke[4], where the author created something with what he thought were obviously bad ideas, but people liked some of them. Ansible is so obviously bad, at its core, that I actually went and read the first dozen Git commits to see if there were any signs that is was an April Fool's joke.

There was a time a few years ago when Ansible's website said things like "agentless", "masterless", "fast", "secure", "just YAML". They are all a joke.

Ansible isn't agentless. It has a network agent that you have to install and configure (SSH). Yes, to do it correctly you have to actually configure SSH, a user, keys, etc. It also has a runtime agent that you have to install (Python). You have to install Python, and all the Python dependencies your Ansible code needs. Then it has the actual code of the agent, which it copies to the machine each time it runs, which is stupidly inefficient. It is actually easier to install and configure the agents of all the other config management systems than it is to properly install, configure, and secure Ansible's agent(s).

Masterless isn't a good thing, and a proper Ansible setup wouldn't be masterless. The way Ansible is designed is that developers run the Ansible code from their laptops. That means anyone making code changes needs to be able to be able to SSH to every single server in production, with root permissions. And it also risks them running code that hasn't been committed to Git or approved. Any reasonable Ansible setup will have a server from which it runs, Tower, a CI system, etc.

Fast. Ha! I benchmarked it against Salt, wrote the same code in both, that managed the exact some things. Using local execution so Ansible wouldn't have an SSH disadvantage. Ansible was 9 times slower for a run with no changes (which is important because 99.9% of runs have no or few changes). It is even slower in real life. Why is it so slow? Well, SSH is part of it. SSH is wonderful, but it isn't a high performance RPC system. But an even bigger part of the slowness is the insane code execution. You'd think that when you use the `package` or `apt` modules to ensure a package is installed, that it would internally call some `package.installed` function/method. And that the arguments you pass are passed to the function. That is what all the other configuration management systems do. But not Ansible. No, it execs a script, passing the arguments as args to the script. That means every time you want to ensure a package is still installed (it is, you just want to make sure it is), Ansible execs a whole new Python VM to run the "function". It is incredibly inefficient.

Secure. Having a network that allows anyone to SSH to any machine in production and get root isn't the first step I'd take in making servers secure.

It isn't just YAML. It is a programming language that happens to sort of look like YAML. It has its own loop and variable syntax, in YAML. Then it has Jinja templating on top of that. "Just YAML" isn't a feature. To do config management correctly you need actual programming language features, so use an actual programming language.

If I had to pick one again, I'd pick Salt. Specifically I'd use Salt with PyObjects[5] and PillarStack[6].

But I'll reiterate, you shouldn't start with a config management system. Start with something fully managed. Once you need a config management system, take the time to do it correctly. Like it should be a six week project, not a thing you do in an hour. Chef and Salt will take more time to get started, but if setup correctly they will be much better than any Ansible setup. If you don't have the time or knowledge to do Chef or Salt correctly, then you don't have the time or knowledge to manage VMs correctly, so don't.

[1] https://cloud.google.com/container-optimized-os

[2] https://aws.amazon.com/bottlerocket/

[3] https://docs.saltstack.com/en/latest/ref/renderers/

[4] https://en.wikipedia.org/wiki/Flask_(web_framework)#History

[5] https://docs.saltstack.com/en/latest/ref/renderers/all/salt....

[6] https://docs.saltstack.com/en/master/ref/pillar/all/salt.pil...

Thanks, that was a very clear explanation. I know AssumeRole is needed for SSO, and I understand the benefits of SSO. The way the article phrased it it sounded like AssumeRole has some very specific benefit by itself.

And if the answer is "short lived credential", then I'd like to understand how short lived credentials that require a long lived credentials to get them are better than long lived credentials, if both can be just as easily revoked.

I'd like more detail on the advantages of AWS AssumeRole, and what attacks it is designed to protect against. It must be more than CloudTrail logs, because normal API usage gets logged to CloudTrail.

One thing I'd like to highlight is that SOC2 is about having controls (of your choosing), and documenting and proving you are following those controls. I think it is important to pick controls you actually want to follow, and that those controls aren't so specific that you get fenced in to a bad process.

I've worked at a few companies that have gone through SOC2, one of them (Dropbox) did it very well. I think the average engineer didn't need to know about SOC2, or what all the controls were, because the controls were well thought out, and automation took care of the proof. At another company every engineer was constantly saying "you have to do that because of SOC2", because the controls intruded on the way engineers worked.

"SOC2 requires that two people approve every PR". Hmm, no the accountants that created SOC2 don't know what PRs are. "Only members of the team called 'QA' are allowed to transition Jira tickets from state A to state B, SOC2 requires it". No, I'm pretty user SOC2 doesn't specify issue tracker workflows. "You need to name your git branched XYZ-abc-foo-bar, because of SOC2". You're telling me that accountants are specifying source control conventions?

For 2020 Honda only has a single model in the US that starts below $20,000, the Honda Fit. And that is only for some trim levels of the Fit. In 2019 Honda sold 35,414 Fits, out of 1,450,785 total Honda vehicles sold[1] (384,168 CR-Vs, 325,650 Civics, 267,567 Accords, being the top sellers).

So roughly 2% of Honda vehicles sold in the US cost less than $20,000, and that is without taxes and other fees. The Ford F-150 is the best selling vehicle in the US, and the average transaction price of an F-150 (as sold) is around $50,000. New cars under $20,000 basically don't exist in the US.

[1] https://carsalesbase.com/us-car-sales-data/honda/

Site Reliability Engineer (SRE)[1]. Read the SRE book (https://landing.google.com/sre/books/). Study any gaps you have. Tailor your resume and talking points to the job/direction you want, meaning de-emphasize some things, while still showing your career path and depth. Look to work at a big-ish company that is respected for engineering quality, where you can learn from others and from existing good practices. It doesn't need to be a Google or Facebook sized company, something around the size of Dropbox, Lyft, Stripe, and similar would be good.

[1] Really, "Development (full stack), server admin, data center management, DevOps, project management, managing teams, VoIP, routing/switching" is a perfect fit for SRE, and SRE probably is the most in-demand and highly paid of all the related fields (software development, etc.).

The short answer is KMS doesn't store secrets.

You can use KMS as part of your own secret manager, but you would have to store the actual secrets somewhere else, like GCS or Datastore. KMS stores encryption keys, and has an API for encrypting/decrypting. For example to retrieve a secret using KMS you would get the encrypted data from where it is stored, like Datastore, and send it to KMS to have KMS decrypt the data. Secret Manager actually stores the secret, so a single API call can retrieve the decrypted value. Secret Manager also has versioning, which is important when rotating secrets. If you were building your own solution around KMS you would need to do versioning in your storage schema, wherever you end up storing the secrets.

Why? I'm genuinely curious. I've never used their product, but their Wikipedia page says they are a San Francisco based company with end-to-end encrypted messaging and video conference calls[1]. And their home page[2] says "Fully encrypted. Enterprise-ready. Private."

At first glance it seems like a reasonable choice. US based and end-to-end encrypted seems to be what the military wants in this case.

[1] https://en.wikipedia.org/wiki/Wickr

[2] https://wickr.com/

The specifics of Chef's licensing are unrelated to my appreciation for their install.sh script, I just think it is a good example of a robust cross-platform install script.

That said, last year Chef changed their licensing[1]. My understanding is that their code is now all open source under Apache License 2.0 (there used to be a split between open source and commercial). But, and this is a big BUT, their distributions (installers, compiled code, etc.) are not open source. This is similar to Red Hat where all the main code in RHEL is open source, but they don't provide an ISO to install RHEL.

If you are looking for server configuration management, I've used all four of the major ones (Puppet, Chef, Salt, and Ansible), I'd recommend giving SaltStack[2][3] a look. The PyObjects renderer[4] is especially interesting because it allows writing the configuration in a full programming language (Python), similar to how Chef configuration is written in Ruby.

[1] https://www.chef.io/press-release/chef-open-sources-100-perc...

[2] https://www.saltstack.com/

[3] https://github.com/saltstack/salt

[4] https://docs.saltstack.com/en/master/ref/renderers/all/salt....

Along those lines, Chef's install.sh is the most impressive install shell script I've seen:

https://omnitruck.chef.io/install.sh

It works with pure sh, not just bash. It works on Red Hat, Debian, Solaris, AIX, and macOS. It works even if curl and wget aren't installed.

GCP has different SLAs for each product, but the ones I've seen are per-customer. The details vary by service, but they generally define downtime, like x% errors for y% amount of time, and then have financial penalties for z% downtime[1]. There are sometimes clauses requiring retries with exponential backoff[2].

Their SLAs are short and readable. It is worth reading a few of them, especially if you have a SaaS and are thinking about your own SLAs. Just search Google for [google $product sla] to find them.

[1] https://cloud.google.com/stackdriver/sla

[2] https://cloud.google.com/datastore/sla

The Union Station (EarthCent Ambassador) series by E. M. Foner[1]. They are fun lighthearted sci-fi about the characters and their lives. But under the lighthearted fun hides thought provoking commentary on society and people. The books are included with Kindle Unlimited so if you are a member of that you can read the books at no additional cost.

[1] https://www.amazon.com/dp/B00K4I391A

There was JavaOS: https://en.wikipedia.org/wiki/JavaOS

Yarn has `yarn licenses list`[1], which is very useful. And there is an accepted RFC for `yarn licenses check`[2] they would check against a list of allowed licenses.

[1] https://yarnpkg.com/lang/en/docs/cli/licenses/

[2] https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-li...

I want to put on end to the "you can't contact Google" comments that comes up every time Google Cloud makes the front page.

You can contact Google Cloud. They are very responsive. I'm currently at a small startup using GCP, and I've been at similarly sized startups with equivalent AWS spends. I have found it easier to have serious discussions with GCP, compared to AWS.

We have dedicated GCP contacts. We actually have a Slack channel we share with our dedicated GCP contacts, so we can easily ask questions. Two of my coworkers just got out of a meeting with Google PMs less than an hour ago. Another one will be meeting at a Google office tomorrow. I had a meeting with about a dozen Google engineers and PMs from their database team(s).

Yes, you have to pay for support. They have a couple different support options, depending on your needs. But you have to pay for support with AWS too.

The one bad thing about Google Cloud support is their Level 1 support. It is very easy to submit a support ticket, and they will respond quickly. But if you are highly technical, and know what you are doing, and can research yourself, Level 1 support it nearly useless. They do make it easy to to escalate, with a prominent Escalate button in the ticket. And you can always escalate through your direct contacts (Account Manager, Technical Account Manager, Customer Engineer). But it would be nice if Level 1 could be bypassed, or were more technical. I think they are trying to iterate on the process. They recently started offering to have a video call a lot of the time, which isn't my cup of tea, but I think it is a sign that they are trying to improve the Level 1 support.

If you are using Google Cloud as part of a business, you will be able to contact them. You will probably have an account manager that you can probably meet in person with. If you pay for support you will be able to submit support tickets, real humans will respond, and respond quickly.

Section 2870 of the California Labor Code[1]:

> Any provision in an employment agreement which provides that an employee shall assign, or offer to assign, any of his or her rights in an invention to his or her employer shall not apply to an invention that the employee developed entirely on his or her own time without using the employer’s equipment, supplies, facilities, or trade secret information except for those inventions that either:

> (1) Relate at the time of conception or reduction to practice of the invention to the employer’s business, or actual or demonstrably anticipated research or development of the employer; or

> (2) Result from any work performed by the employee for the employer.

> (b) To the extent a provision in an employment agreement purports to require an employee to assign an invention otherwise excluded from being required to be assigned under subdivision

> (a), the provision is against the public policy of this state and is unenforceable.

Any such agreement must also state that it does not apply to an invention that qualifies under Section 2870[2].

[1] https://leginfo.legislature.ca.gov/faces/codes_displaySectio...

[2] http://leginfo.legislature.ca.gov/faces/codes_displaySection....

"Extreme Ownership" by Jocko Willink and Leif Babin. I highly recommend the audiobook, it is narrated by the authors and is very engaging.

Some of the comments in this thread say that military orders and life and death situations don't apply in the business world. But that isn't what this book is about, the advice is really the opposite of giving orders the must be followed without question. And the lessons are explained in ways that clearly relate to business management.

One of the killer features of Cassandra is cross-region replication with location aware consistency for queries. It looks like in this preview of Manages Cassandra Service they are only supporting single regions clusters. I do hope they support multi-region clusters in the future.

It would also be nice if they documented any differences from Apache Cassandra, like if Amazon MCS improves secondary indexes so they can be used in more cases.

Here you go, programming languages and their salaries:

https://insights.stackoverflow.com/survey/2019#top-paying-te...

Readme Driven Development, a term I first saw used by Tom Preston-Werner (GitHub founder): https://tom.preston-werner.com/2010/08/23/readme-driven-deve...

I find it to be a great method of development. The core use case (what the project is and why it exists), and the public interface are so important, and often overlooked when people start a project by writing the code first. I tend to write the README in my head naturally, before I start a project, so writing it down makes sense.

I also like to write the developer guide part of the README at the beginning (how to setup a development environment), so I ensure the project is easy to contribute to.

It may have been buggier yesterday, but I had the change applied to my desktop client today and it is still buggy. Try to edit an `inline code` section. Or enter two code blocks back to back. Or paste in anything with formatting, especially if there is a code block at the end.

I've just had this change hit my desktop client, so it isn't web only. It is very broken. Jira's new issue formatting is probably still worse, but I use Jira less than Slack.