>Due to broken MIME parsers a bunch of MUAs seem to concatenate decrypted HTML mime parts which makes it easy to plant such HTML snippets.
To me this sounds strictly like a MUA issue, not a PGP/SMIME one. If that's really all it is it does seem massively overblown to me. Why not single out the broken MUA implementations instead of saying "don't decrypt emails OR YOU'LL DIE"? I mean just look at the wild speculation in this thread, nobody understood what was going on or even what was really vulnerable and what wasn't. Given the alarmist tone and the claims of "no workaround available" I was personally expecting a deep conceptual flaw in PGP/SMIME themselves. Terrible communication IMO. The parent email in the GnuPG thread seems to agree: https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...
Sounds like this has been handled absolutely terrible both by the original researchers and EFF. The researcher then trying to shush the directly affected GPG developers on Twitter, evidently just for the sake of a stupid no-prior publication bullshit for their paper just adds to it.
I dunno, a client issue like this seems pretty terrible to me since there is no obvious (to me) way to fix it. If I am encrypting a message, I have no control over what client decrypts it (and whether that client unwittingly passes the information along) without maybe changing the standard completely.
The thing is, If I am reading correctly, it seems like this kind of vulnerability seems totally predictable.
I agree, after getting the details it's fair to say that while some MUAs should fix their handling of encrypted emails PGP implementations and the S/MIME standard shares a part of the blame by not detecting and preventing the decoding of tampered documents. Still, the way the problem was disclosed is rather misleading and confusing.
Oh, I thought you were making the "email should only be text" argument, not the "you should avoid looking at the non-text part of multipart email" argument. I was addressing the former.
You are not alone, see the following exchange on LKML, where Donenfeld immediately "disciplines" another subscriber for asking some minor question that was not 100% on topic:
Just take a look at VBoxManage --help for a crazy list of settings and features that VBox has accumulated during the past ~10 years.
It even supports ATA TRIM so your fs-driver can discard blocks and keep the VDI-file deflated at all times.
Performance-wise: Compiling stuff within VBox on an i7 quad-core (-j5) is almost as fast as native. X on Linux-VMs feels native too, especially when running in fullscreen.
Out of curiosity, have you tried anything other than VirtualBox (e.g. VMware Fusion)?
I was happy with VirtualBox's (on OS X) performance until I bought VMware Fusion. I didn't do any benchmarks so I don't have numbers to back up my claim but it definitely "felt" much faster than VirtualBox.
I never tried VMF so it may be faster, sure. The thing about VBox is, like I wrote, features. VBox is basically a full-featured Virtualization-Suite, has multiple UIs and an API. It is also available on Win7,8,10/macOS/Linux and Solaris.
You may add: excellent documentation and friendly support (board, irc, list).
If I'll ever have to switch, I'd first need feature-parity.
Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host's wireless adapter, and therefore VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter's MAC address and passes it on. VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines.
So what? Many standards originated from some particular need of one or two companies popular at that time. Look at the current IETF WGs and the authors of the drafts they produce.
