achernya

Yes, mosh has fuzz tests in oss-fuzz [1].

[1] https://github.com/google/oss-fuzz/tree/master/projects/mosh

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.

[1] https://nvd.nist.gov/vuln/detail/CVE-2012-2385

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.

https://peering.google.com/#/infrastructure has maps of Google CDN infrastructure.

(work at Google, and on the CDN)

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.

Following up on this, there's discussion on github [1] about this, and we're currently leaning towards allowing URIs.

[1] https://github.com/DavidSchinazi/draft-cms-masque-connect-ip...

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].

[0] https://quiche.googlesource.com/quiche/+/refs/heads/master/q...

[1] https://tools.ietf.org/html/draft-ietf-masque-ip-proxy-reqs-...

[2] https://tools.ietf.org/html/draft-cms-masque-connect-ip-00

It looks like the links to the code have some junk characters at the end. It should be https://github.com/wsmoses/Enzyme.

Author here -- MIT does not currently have IPv6. Although MIT did receive a /24 IPv6 allocation, https://whois.arin.net/rest/net/NET6-2603-4000-1, it's not routable everywhere on campus yet.

Unfortunately, IPv6 deployment is still below 20% (as measured by Google, https://www.google.com/intl/en/ipv6/statistics.html) so a publically-accessible IPv6 address is not yet sufficient.

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.

That is not sufficient -- TLS Server Name Indication (SNI) is still cleartext in the handshake.

> 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)

Is there a comparison of reTTY with reptyr (https://github.com/nelhage/reptyr)? reptyr claims to work with less while reTTY does not.

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.

I'd like to congratulate all the students for all of their hard work. 6.858 always produces new, original results, and this year is no different.

More details on http://pki.google.com/.

This has the problem of "where does the first hacker come from?" Then I realized the first hacker is almost certainly Ada Lovelace, who wrote the first computer program for Babbage's Analytical Engine.

I've used mosh over iodine, by simply having the iodine-server forward all of my packets via IPv4 NAT. I then set my client gateway to use dns0 instead of eth0. Works great!

Assuming you are running the latest Fedora, you can get the SRPM from the main Fedora Project servers: http://dl.fedoraproject.org/pub/fedora/linux/updates/16/SRPM...

There are source and binary packages for Fedora 15, 16, the upcoming 17, and rawhide. You can configure your yum to use dl.fedoraproject.org instead of a choosing a mirror to get the latest updates, if you want.