It works but it shows phone numbers rather than contact names and you can’t assign a name to a number without giving access to your entire contacts … it ticks me off.
No, it isn’t. Browser root programs have certificate transparency (SCT embedding) requirements which would immediately reveal to the world if an ISP started to use a trusted root to MITM its users.
I think the title buries the most horrifying part of this. The HiCA certificate authority is relying on an RCE to do an end-run around the semantics of the ACME HTTP-01 validation method.
Fucked up and they should be booted from every root program for this.
They aren't in any root programs. They're just taking certificate requests and relaying them to real CAs, which is why they need to exploit an RCE in the ACME client, since the ACME client wouldn't otherwise be able to complete the validations required by the actual CA.
When confronted they just flat out shut down the service. They also donated $1000 to the project, and they've redirected requests to their payment site to the US White House's website, and they're from China.
They were also suggesting that user's ran the utility as root...
There is years and years and years of amazing content and community on Reddit. Rallying people around a replacement looks challenging. I am hopeful that it happens.
They're solving the same "high level problem", but with very different approaches.
TensorRT is proprietary to Nvidia and Nvidia hardware. You'd take a {PyTorch, Tensorflow, <insert some other ML framework>} model and "export / convert" it into essentially a binary. Assuming all goes well (and in practice rarely does, at least on first try - more on this later), you now automatically leverage other Nvidia card features such as Tensor cores and can serve a model that runs significantly faster.
The problem is TensorRT being exclusive to Nvidia. The APIs for doing more advanced ML techniques like deep learning optimization requires significant lock-in to their APIs, if they are even available in the first place. And all these assuming they work as documented.
OpenXLA (and other players in the ecosystem like TVM) aim to "democratize" this so there are more support both upstream (# of supported ML frameworks) and downstream (# of hardware accelerators other than Nvidia). It's yet another layer or two that ML compiler engineers will need to stitch together, but once implemented, they in theory can do a lot of optimization techniques largely independent of the hardware targets underneath.
Note that further down in the article they mention other compiler frameworks like MLIR. You can then hypothetically lower (compiler terminology) it to a TensorRT MLIR dialect that then in turn runs on the Nvidia GPU.
>You can then hypothetically lower (compiler terminology) it to a TensorRT MLIR dialect that then in turn runs on the Nvidia GPU.
there's no tensorrt dialect (there are nvgpu and nvvm dialects) nor would there be as tensorrt is primarily a runtime (although arguably dialects like omp and spirv basically model runtime calls).
TensorFlow is also a runtime, yet we model its dataflow graph (the input to the runtime) as a dialect, same for ONNX. TensorRT isn't that different actually.
OpenXLA is an open-source library for accelerating linear algebra computations on a variety of hardware platforms, while TensorRT is a proprietary library from NVIDIA that's specifically designed for optimizing neural network inference performance on NVIDIA GPUs.
openxla is a ML-ish compiler ecosystem built primarily around mlir that can target (through nvptx backend in llvm) and run on nvidia devices (on iree). tensorrt is a runtime for cuda programs. certainly they have features in common as a reflection of their common goals ("fast nn program training/inference") but the scope of tensorrt is much narrower.
Is Amazon-managed encryption (SSE-S3) mostly a checklist/regulatory thing? Like, is it mainly protecting against somebody walking out of a DC with a storage device?
Yes. This is really a non-announcement. S3 has had configurable encryption since at least 2011. And Google cloud storage has had default encryption at rest since 2013. For a decent explanation of encryption at rest check out https://cloud.google.com/docs/security/encryption/default-en...
Or some other kind of hack/data theft. That's what it looks like to me.
I don't see it as just a checklist thing: if Amazon ever gets hacked, you wouldn't want your data compromised as a result. Of course, if they manage to steal the keys too, it would still be.
I would have assumed that's always the case for all storage devices? Or am I naive? I would expected any cloud provider to do that, even if it's just to make disposing old drives easier.
In this context, I think "requires DNSSEC" is an opinion at best. "Requires" is probably the wrong word.
You are welcome to use CAA accounturi without DNSSEC and it will be effective.
Your zone may be vulnerable to an active man-in-the-middle DNS attack (which is hard to pull off), but it will still be protected against somebody figuring out how to upload an /.well-known/acme-challenge/ file on your domain and issue an unauthorized certificate from a foreign ACME account. This attack is much easier - I did it against a popular mail provider a few years ago.
In 2014 Rob Mueller wrote: "Our future DNS plans include DNSSEC support (which then means we can also do DANE properly, which allows server-to-server email sending to be more secure), DMARC record support, and ideally one day Anycast support to make DNS lookups faster."
