<joepie91>
MichaelRaskin: honestly, the whole concept of SGX has always been deeply flawed
<joepie91>
and this break is merely a practical manifestation of the inevitable failure mode
<joepie91>
it's really no meaningfully different from all the past 'user-tamperproof processing chip' ideas
<andi->
I guess it is bad if you bet on that horse.. I seriously don't get why one would do that tho.. Maybe I am short sighted but it feels like the ultimate vendor-lock-in and blackbox trust..
<joepie91>
andi-: well, the reason some people bet on that horse is that if you ignore the obvious flaws it feels like it solves a bunch of unsolvable problems
<joepie91>
the real question is why some people *who should know better* also bet on that horse...
<MichaelRaskin>
Rutkowska said peple almost coninced Intel to allow actual useful applicatins of SGX. Trusting Intel and AMD for low stakes is not much different from Amazon.
<joepie91>
MichaelRaskin: the problem is that I've not seen compelling usecases of SGX that aren't also met by things-that-are-not-SGX
<joepie91>
low-stakes usecases are easy; you don't need SGX for that, we have plenty of other solutions already
<MichaelRaskin>
Efficient low-overhead computation outsourcing has an area of parameters where SGX could make sense if Intel were not so cofident in their stance that SGX is oly for malware
<MichaelRaskin>
Ah right, nice observation in that article: L1TF is worse for VMs than for containers.
<andi->
So, there is a new OpenSSL version since yesterday. I am trying to figure out if we already have a commit for that. If I followed that staging workflow correct I must check staging-18.03, master, staging and staging-next if it might have appeared somewhere already?
<ivan>
git fetch; tig --all, /openssl
<andi->
oh, tig --all was new to me
<andi->
thanks ivan :)
<ivan>
np
<ivan>
or tig --all --date-order
<andi->
I was silly.. I attempted updating openjdk7... It's the aarch64 experience all over again.. Reading those changelogs is scary.