Really? Bummer. I hope the community keep a steady pace at development and don't let it die. Having another engine competing with the "titans" of the current web would bring so much benefit (I think and hope so).
The "recent" event[0] with Chrome dev team scared me; they have so much power to change things "at will".
Everyone is "guaranteed" a fair trial. As much as one can guarantee such a thing. Bill Cosby was just let out of prison because of shenanigans with his trial.
It's true that there are "higher level" races that Rust can't prevent. But in-memory races are particularly important to prevent, because a) they're a common and very nasty kind of bug and b) it means unlike Go, Rust (the safe subset) is memory safe (and in general, free of undefined behaviour) for concurrent code.
That's exactly what I referred to: The function takes two BigInt's, which you have to unpack yourself from the byte-serialization created by JS. There's no JS-compatible ECDH key derivation function in Golang either, so you have to implement the multiplication yourself (which again isn't difficult).
My impression is that crypto people, being mildly allergic to asn.1, decided not to use it to specify standard serialization formats in our new world of EC crypto. So here we are without asn.1 and without a replacement. I generally think if you’re going to remove something because you think it sucks it’s on you to replace it with an equivalent or clearly justify why it was vestigial if you don't have one.
In this case you really don't need a DER calibre encoding either, you just need a standard in the first place. It’s just that the standard would historically likely use asn.1. But that doesn't have to be the case. Maybe the closest thing is the ECDSA point form specified in https://www.secg.org/sec1-v2.pdf#page16. The the curve domain parameters in sec2 are, you guessed it, specified in asn.1.
AMD SME protects against physical access attacks. To my knowledge no process-based enclave solution was presented by AMD based on SME.
Instead AMD went the route of VM-based enclaves in the form of SEV. Intel is following this direction with TDX.
The concept of VM-based enclaves is slightly different and trades a larger Trusted-Computing-Base (TCB) for better lift-and-shift.
You could run unmodified Go applications in your SEV/TDX VM so there is no need for EGo in this context.
Potentially we'll add attestation features for SEV/TDX for our enclave- and client-libraries that are part of EGo.
Here is a (slightly outdated comparison) of SGX and SME/SEV: https://caslab.csl.yale.edu/workshops/hasp2018/HASP18_a9-mof...
Although you can move freely to any country, to recieve benefits in a most countries you need to have had a job for 3 months before you can claim any benefits.
