The only mosh CVE [1] was in the terminal emulator (a DoS that could only be triggered by a local user), not in the protocol. There have been no vulnerabilities in mosh's UDP protocol.
QUIC datagrams not having a stream ID was a compromise, which is why the H3-DGRAM draft exists to add them. Any other protocol can use cite and use H3-DGRAM even if it itself is not using HTTP/3.
futex is a Fast Userspace muTEX. It's the syscall to help implement a mutex when there are two or more threads waiting on the lock to let other processes/threads schedule and do useful work during the wait.
Right now we're focusing on building a functional core protocol and making sure it's sufficiently extensible. It should be possible to build chaffing as an add-on extension down the line.
We have built a VPN over QUIC, and the core code is open source already [0].
We're working on standardizing "IP Proxying" over QUIC as part of the MASQUE working group at IETF. So far, we've adopted a requirements document [1] and have started work on an implementation [2].
The specific detail that you've noticed in the Go implementation has to do with RFC 7540, Section 9.2.2 (https://tools.ietf.org/html/rfc7540#section-9.2.2) which requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS 1.2 only. Deployments of the future TLS 1.3 are free to not support this cipher, if I am reading the RFC correctly.
That is to say, you're correct that server configured for a 100% on SSLLabs will not support HTTP/2, but I agree with davidben that SSLLabs is incorrect here for incetivising AES-256, particularly in CBC mode, for the 100% score.
I ran a nearly identical screen theme for a long time, before switching to byobu. Nice to see this broken down, screen's format strings are quite dense.
> In addition, the tech support was wonderful. A few years after I graduated I remembered a blog I had kept from my athena account, and emailed in to ask if they happened to still have it. They kind of did; they sent me a SQL dump of its contents, which was enough for me.
While it's true that helpdesk at IS&T was all sorts of wonderful prior to the transformation, that particular example wasn't handled by them, but rather by the student volunteers running Scripts (scripts.mit.edu), part of SIPB (sipb.mit.edu). SIPB does get its funding from IS&T, and worked pretty closely with many people there on initiatives ranging from the Scripts platform to the whole Athena operating system.
I don't know if the "fast and free infrastructure" and "friendly tech support" will continue, as it requires the new IS&T to continue supporting the student volunteers.
Which qemu are you cloning? When we taught 6.828 over IAP term we ported the patches to qemu 1.7.0 and put them up at https://github.com/geofft/qemu. I see the repo has a 2.3.0 and 2.4.0 branch now too. I last built 1.7.0 on Debian 6 (squeeze); newer Debian and Ubuntu should work fine. (Make sure you have libsdl1.2-dev installed)
It's not that much of a myth. When Google first announced that the Galaxy Nexus was not getting KitKat, I was pretty disappointed, as I had one too. I looked into why there was no official support, and when I found out it had to do with the firmware, my gut reaction was "WTF, that makes no sense." Digging some more, I found out that it actually has to do with kernel driver-firmware compatibility. Google wanted to ship an update, but they needed changes that TI was no longer willing/capable of making. In order to release KitKat on the Galaxy Nexus would either require Google to reverse engineer the hardware and make their own radio firmware (not likely) or holding back the kernel to the same one on 4.3 (subpar experience if it even works).
Neither the Glass nor Moto 360 suffer from this problem since neither has a cellular radio.
I'm not sure it's reasonable to expect Google to update a device to the latest version when the hardware manufacturer has exited the market -- http://www.cnet.com/news/google-to-samsung-galaxy-nexus-owne.... While Google does control Android, that's not the only software that is present on the phone. Short of the Nexus series starting to have open source baseband and radio firmware, we'll be at the mercy of hardware manufacturers.
You're correct, the protection is implemented in hardware, but the pages have to be marked appropriately. This message describes a patchset that correctly marks the kernel pages as writable xor executable.
This was one of my favorite classes, so much that a few of us were crazy enough to offer a January term version of it last year. The material is the same, but the website formatting is for the labs a bit different, and may be more readable to some: https://sipb.mit.edu/iap/6.828/. It's doable to finish all of the labs in an intensive month, and a great experience. I do recommend going through the exercises.
[1] https://github.com/google/oss-fuzz/tree/master/projects/mosh