Any update on this  <i><b>critical</b></i> bug, since the release of Saucy didn't see a change to its status?

This bug is closely related to <a href="https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/420080">Bug 420080</a>, which itself tried to address and issue already reported in... <i><a href="https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/155987">2007!!</a></i> Linked Debian bug is <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451535"#451535</a>. @cjwatson had proposed a patch for this long standing issue of detecting and opening existing encrypted partitions so as to reuse them, but it diesnt't seem implemented in Debian 7 Wheezy, while the bug status has been set to "Wishlist" (??!).

The summary of the situation is :
- Ubiquity doesn't offer to unlock encrypted partitions, and instead say they are empty, hence offering to format them.
It is exactly the same case in Debian, where it is even worse because the default install medium is a net-install image, which doesn't provide the opportuinity to open a live session and thus applying the recommended workaround (access and unlock concerned partitions through GUI file manager/disk utility before launching the installer); in Debian, one has to change TTY and follow a cryptic procedure based upon anna-installing/modprobe-ing stuff... And then still has to chroot and create a crypttab before rebooting.

- What is causing this behaviour (which is apparently a regression)? Is it that ubiquity doesn't read the LUKS headers of said partitions, and hence doesn't recognise them as encrypted and offer to open them ? In that case is it possible to (re-)implement the detection and choice for opening (cryptsetup author says it's really easy to recognize LUKS container), while having a conditional jump saying "if partitions are encrypted don't offer to resize" so as not to mess with partman inability to resize lvm and dm-crypt devices ? <a href="https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#1._General_Questions">cryptsetup FAQ</a> is quite vocal about Ubuntu's installer being a "LUKS killer"...

 - I understand the reasoning behind <a href="https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1046779/comments/2">xnox' comment</a>, but consider the following use case: 

        - Users take care of partitioning and encrypting+lvming the device before installation, or more simply wish to re-use pre-existing partition scheme (clean upgrade etc.); 
        - They then want to install Ubuntu within the predesigned layout;  
        - They fall short doing so because the installer EVEN IN MANUAL MODE the installer doesn't recognise the encrypted volumes ; 
        - They feel weird or rightly outraged because it's perfectly do-able from a live session, by opening partitions first through a GUI utility and then launching the installer (i.e. release notes' workaround);
        - As underlined in the original bug report, the current behavior has as much chance to cause data loss as the possibility to resize such encrypted/lvmed partitions (happened to me with d-i for Debian Wheezy) 

On a side note, I must say that I find it at least urprising, if not directly worrying that a bug marked as "critical" found its way past Saucy's release, while it's been in such a critical state for so long. People who would like to maintain full disk encryption or other encrypted setup (as a consequence to recent revelations about massive surveillance or other related scandals, for example) aren't really well served with Ubuntu (or any Debian-based disro, as I get it)...

What about fixing this for Trusty/14.04, for this LTS not to be crippled by such a privacy/usability breach?