CryFS 0.10.X versions don't support opening encrypted containers created with 0.9.x series, as per https://github.com/cryfs/cryfs/releases/tag/0.10.1 . The following message is shown when trying to mount such a container: ``` $ cryfs ~/folder.enc /folder CryFS Version 0.10.2 Password: Deriving encryption key (this can take some time)...done This filesystem is for CryFS 0.9.6 (or a later version with the same storage format). You're running a CryFS version using storage format 0.10. It is recommended to create a new filesystem with CryFS 0.10 and copy your files into it. If you don't want to do that, we can also attempt to migrate the existing filesystem, but that can take a long time, you won't be getting some of the performance advantages of the 0.10 release series, and if the migration fails, your data may be lost. If you decide to continue, please make sure you have a backup of your data. Do you want to attempt a migration now? Your choice [y/n]: n Error 14: This filesystem is for CryFS 0.9.6 (or a later version with the same storage format). It has to be migrated. [Exit 14] ``` There are two options as suggested: - Creating anew container with new cryfs, then opening container with old cryfs, and copying files over. - Risk migration that could lead to data loss. This is clearly a breaking version change, considering that CryFS is not only used manually but also as a backend for KDE Plasma Vaults., that can lead to data loss. Additionally safe migration is only possible, without storing data unencrypted on disk, is to have both versions available at the same time. Looking at the projects release page we can also see that 0.9.x and 0.10.x series are both released in parallel for the time being. As per https://devmanual.gentoo.org/general-concepts/slotting/index.html this package has to be slotted and either a info message at the end of the emerge, or better a eselect news item should warn users of the breakage and give them a guide for migration.
Altough the idea is noble, in practise it falls short of: - package does not support parallel install (files conflict) - consequently, binaries are named identically, if you rename them, you'll have to create an eselect module; revdeps will all expect the standard naming - cryfs-0.9* depends on <boost-1.70, cryfs-0.10* depends on >=boost-1.70, boost is not slotted either, which means down- and upgrades are especially painful for the triggered slot rebuilds This is more smelling like a news item for stable users to temporarily store their data unencrypted, do the upgrade, and move their files back to a new encrypted storage.
I see, so slotting would have unrealistic requirements. Alright, thanks for the explanation. Then @Andreas can you please make sure that there is a news item for this, as this can bite stable users? Also maybe keep 0.9.x and 0.10.x series in stable for a while in parallel allowing users to migrate easily.
"When trying to migrate a file system from CryFS 0.9.3 or older, show an error message suggesting to first open it with 0.9.10 because we can't load that anymore." cryfs entered portage with version 0.9.7. So it appears to me we do not need to do anything here at all?
See also commit: https://github.com/cryfs/cryfs/commit/5a5f8f732419abeaaf078a9ce0212f3c3aa4a1c2
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef111452b8fc7243d3a69e51bcc396498a01a50f commit ef111452b8fc7243d3a69e51bcc396498a01a50f Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2019-10-26 20:07:22 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-10-26 20:15:17 +0000 sys-fs/cryfs: Revert "Add upper bound on boost-1.70" It appears to build just fine against boost-1.71.0. This reverts commit 4f8c83514f1d7664bcccdba3d8ffd3de7ef5325b. Bug: https://bugs.gentoo.org/690324 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> sys-fs/cryfs/cryfs-0.9.9.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sorry, different issue. I was actually able to reproduce your message. However, the situation is not as dire as initially thought.
News Item draft: https://archives.gentoo.org/gentoo-dev/message/1a31f1fce6dc54c24dfb4f1946125d62
The news item looks reasonable and informative engough, thanks for making it. I'll let the official devs approve it.
