** Description changed: CryFS 0.9.10 fixed a dead lock and a race condition, the latter of which can cause data loss if the file system is under heavy load and accessed concurrently. Changelog: https://github.com/cryfs/cryfs/blob/0.9.10/ChangeLog.txt Some user reports about the data loss: - https://github.com/cryfs/cryfs/issues/243 - https://github.com/cryfs/cryfs/issues/224 - https://github.com/cryfs/cryfs/issues/237 This issue is fixed in 0.9.10 but stable Ubuntu versions (bionic, cosmic) still distribute 0.9.9. The package should be updated in the software repositories. Notes: - A 0.9.10 package is already in Debian and Ubuntu Disco, see https://packages.debian.org/buster/cryfs and https://packages.ubuntu.com/search?keywords=cryfs - Debian will soon update to 0.10, and Ubuntu Disco is expected to follow. However, older Ubuntu versions should not update to 0.10.0 but only to 0.9.10 to fix the data loss bug. - - CryFS has an extensive test suite testing each release, the regression risk is low. [Test Case] Follow the instructions in the linked GitHub issues. Since this is a race condition, it doesn't always manifest, but https://github.com/cryfs/cryfs/issues/224 was quite stable to me: - 1. Create a cryfs file system + 1. Create a file system using CryFS 0.9.9 $ cryfs -f /tmp/basedir /tmp/mountdir Note: the '-f' causes CryFS to run in foreground, i.e. you won't get your terminal back. Keep it running and open a new terminal for the next commands. 2. Create a video file in the mounted directory $ ffmpeg -i some_video_file.mp4 /tmp/mountdir/video.avi 3. Open /tmp/mountdir/video.avi VLC and run it $ vlc /tmp/mountdir/video.avi 4. While it is running, re-create it $ ffmpeg -i some_video_file.mp4 /tmp/mountdir/video.avi 5. Observe the crash in the terminal running the CryFS process + 6. Try the same with CryFS 0.9.10 and observe that it doesn't crash. + [Regression Potential] The race condition was fixed in 0.9.10 using additional mutexes, so the most likely regression is the introduction of a new deadlock. - Generally, CryFS has a very extensive test suite and CI that is run on - each commit and each release, see - https://github.com/cryfs/cryfs/tree/0.9.10/test + Generally, CryFS has a very extensive test suite and CI that is run on each commit and each release, see https://github.com/cryfs/cryfs/tree/0.9.10/test + This test suite is also run automatically when the Debian package is created.
** Description changed: CryFS 0.9.10 fixed a dead lock and a race condition, the latter of which can cause data loss if the file system is under heavy load and accessed concurrently. Changelog: https://github.com/cryfs/cryfs/blob/0.9.10/ChangeLog.txt Some user reports about the data loss: - https://github.com/cryfs/cryfs/issues/243 - https://github.com/cryfs/cryfs/issues/224 - https://github.com/cryfs/cryfs/issues/237 This issue is fixed in 0.9.10 but stable Ubuntu versions (bionic, cosmic) still distribute 0.9.9. The package should be updated in the software repositories. - Notes: + Versioning notes: + - 0.9.10 is a new upstream microrelease. It is preferred to use this new release instead of patching existing packages. - A 0.9.10 package is already in Debian and Ubuntu Disco, see https://packages.debian.org/buster/cryfs and https://packages.ubuntu.com/search?keywords=cryfs - Debian will soon update to 0.10, and Ubuntu Disco is expected to follow. However, older Ubuntu versions should not update to 0.10.0 but only to 0.9.10 to fix the data loss bug. - [Test Case] Follow the instructions in the linked GitHub issues. Since this is a race condition, it doesn't always manifest, but https://github.com/cryfs/cryfs/issues/224 was quite stable to me: 1. Create a file system using CryFS 0.9.9 $ cryfs -f /tmp/basedir /tmp/mountdir Note: the '-f' causes CryFS to run in foreground, i.e. you won't get your terminal back. Keep it running and open a new terminal for the next commands. 2. Create a video file in the mounted directory $ ffmpeg -i some_video_file.mp4 /tmp/mountdir/video.avi 3. Open /tmp/mountdir/video.avi VLC and run it $ vlc /tmp/mountdir/video.avi 4. While it is running, re-create it $ ffmpeg -i some_video_file.mp4 /tmp/mountdir/video.avi 5. Observe the crash in the terminal running the CryFS process 6. Try the same with CryFS 0.9.10 and observe that it doesn't crash. - [Regression Potential] The race condition was fixed in 0.9.10 using additional mutexes, so the most likely regression is the introduction of a new deadlock. Generally, CryFS has a very extensive test suite and CI that is run on each commit and each release, see https://github.com/cryfs/cryfs/tree/0.9.10/test This test suite is also run automatically when the Debian package is created. ** Description changed: CryFS 0.9.10 fixed a dead lock and a race condition, the latter of which can cause data loss if the file system is under heavy load and accessed concurrently. Changelog: https://github.com/cryfs/cryfs/blob/0.9.10/ChangeLog.txt Some user reports about the data loss: - https://github.com/cryfs/cryfs/issues/243 - https://github.com/cryfs/cryfs/issues/224 - https://github.com/cryfs/cryfs/issues/237 This issue is fixed in 0.9.10 but stable Ubuntu versions (bionic, cosmic) still distribute 0.9.9. The package should be updated in the software repositories. Versioning notes: - - 0.9.10 is a new upstream microrelease. It is preferred to use this new release instead of patching existing packages. + - 0.9.10 is a new upstream microrelease. - A 0.9.10 package is already in Debian and Ubuntu Disco, see https://packages.debian.org/buster/cryfs and https://packages.ubuntu.com/search?keywords=cryfs - Debian will soon update to 0.10, and Ubuntu Disco is expected to follow. However, older Ubuntu versions should not update to 0.10.0 but only to 0.9.10 to fix the data loss bug. [Test Case] Follow the instructions in the linked GitHub issues. Since this is a race condition, it doesn't always manifest, but https://github.com/cryfs/cryfs/issues/224 was quite stable to me: 1. Create a file system using CryFS 0.9.9 $ cryfs -f /tmp/basedir /tmp/mountdir Note: the '-f' causes CryFS to run in foreground, i.e. you won't get your terminal back. Keep it running and open a new terminal for the next commands. 2. Create a video file in the mounted directory $ ffmpeg -i some_video_file.mp4 /tmp/mountdir/video.avi 3. Open /tmp/mountdir/video.avi VLC and run it $ vlc /tmp/mountdir/video.avi 4. While it is running, re-create it $ ffmpeg -i some_video_file.mp4 /tmp/mountdir/video.avi 5. Observe the crash in the terminal running the CryFS process 6. Try the same with CryFS 0.9.10 and observe that it doesn't crash. [Regression Potential] The race condition was fixed in 0.9.10 using additional mutexes, so the most likely regression is the introduction of a new deadlock. Generally, CryFS has a very extensive test suite and CI that is run on each commit and each release, see https://github.com/cryfs/cryfs/tree/0.9.10/test This test suite is also run automatically when the Debian package is created. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815320 Title: Potential data loss in CryFS 0.9.9 (fixed in 0.9.10) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryfs/+bug/1815320/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
