I guess so. Although I don’t fully remember if/how that ever worked.
To me that kind of composability feels elegant and Unix-y. A subsystem is explicitly granted access to the plaintext layer device, and it works in a transparent fashion without any special support.
Sure it’s possible to grant this access by mistake, but that’s also true for other kinds of devices. Maybe it should be addressed on a general level if the device widget makes it too too easy by accident, e.g. by misclicking. IIRC there might already be a ticket for that.
Not sure if it’s the central concern. But encrypted storage should be opaque to anyone unauthorized who’s gained physical access to it, and Qubes OS can uphold an unusually strong version of this.
For starters, the dom0 Bash script probably needs a Python rewrite. The design could also use some tweaks, such as not passing the encryption key through dom0 memory (which wasn’t feasible before R4.0), and using a shared DisposableVM for multiple dm-crypt mappings instead of wastefully launching one per device.
Yep, I’ve finally pushed a big commit that adds LUKS2 support etc.
Not much, it’s mostly for convenience.
It aims to prevent data exfiltration from the destination side to the source side, and (theoretical) exploits from the source side to the destination side via malicious block device content like headers parsed by the kernel/udev/cryptsetup.