Comments URL: https://news.ycombinator.com/item?id=48244426

Points: 2

# Comments: 0

If you sell them immediately, then you don't pay any additional capital gains tax, because there were no capital gains from the moment you got them to the moment you sold them.

If you hold on to them, you will eventually pay capital gains on any increase in value from the moment they vested until the moment you sell them.

Perhaps, once they are vested, you could take loans against them, to get some cash while avoiding selling them.

But no matter what, they are taxed at the moment you receive them, and again at the moment they leave your possession.

In practice, it is easy to pick out the situations in which there is "practical" universal jurisdiction, vs "theoretical" universal jurisdiction.

A Colorado company selling locally in Colorado falls in the "theoretical" bucket.

(This is basically how Let's Encrypt / ACME accounts work)

Kubernetes is such a huge project that there are few reviewers who would feel comfortable signing off an an arbitrary PR in a part of the codebase they are not very familiar with.

It's more like Linux, where you need to find the working group (Kubernetes SIG) who would be a good sponsor for a patch, and they can then assign a good reviewer.

(This is true even if you work for Google or Red Hat)

* https://github.com/grpc/grpc-java/blob/master/documentation/...

* https://grpc.io/docs/guides/reflection/

You can then use generic tools like grpc_cli or grpcurl to list available services and methods, and call them.

Take a look at https://github.com/kubernetes/enhancements/tree/master/keps/..., which is hopefully landing as alpha in Kubernetes 1.34. It lets you run a controller that issues certificates, and the certificates get automatically plumbed down into pod filesystems, and refresh is handled automatically.

Together with ClusterTrustBundles (KEP 3257), these are all the pieces that are needed for someone to put together a controller that distributes certificates and trust anchors to every pod in the cluster.

> If the Pool holds the only reference when this happens, the item might be deallocated.

Conceptually, the pool is holding a weak pointer to the items inside it. The GC is free to clean them up if it wants to, when it gets triggered.

I think you need to flip a flag on the cluster object to enable the Gateway controller.

If you salt and hash the password on the client side, how is the server going to verify the password. Everything I can think of either requires the server to store the plaintext password (bad) or basically makes the hashed bytes become the plaintext password (pointless).

There are password-based solutions that work like this --- PAKEs like Secure Remote Passwords: https://www.ietf.org/rfc/rfc2945.txt

They have low uptake because they don't really offer any security beyond just sending the plaintext password over a properly-functioning TLS channel.

Obviously, though, if you almost hit a pedestrian then you aren't properly yielding.

My impression is that Anthos is probably not what you need if your use case is deployment of a managed product into customer GCP projects (or AWS accounts).

Instead, copy the P4SA architecture that GCP uses for managing its own services in your project. Create one service account per customer, and have the customer grant that service account whatever permissions your control plane needs to manage the resources deployed into the customer project.

You can package those permissions into a Role for easier use.

You can see how this works by looking at Google's existing P4SA permissions in one of your cloud projects. They show up in your cloud IAM console if you remove the filter for "Google-Managed Grants".