[Bug 1815320] Re: Potential data loss in CryFS 0.9.9 (fixed in 0.9.10)

2019-05-15 Thread Robie Basak
Thank you for preparing this. I see a couple of minor packaging changes
that don't cause me concern. Everything else looks OK.

@Sebastian it was in the SRU review queue, which is a manual process
that I'm now doing.

@Simon unfortunately Cosmic is still supported, and bumping Bionic up to
0.9.10-1~ubuntu0.18.04.1 will leave it higher than the current version
in Cosmic of 0.9.9-2. I'm not sure this is OK from an archive
perspective. Cosmic still has a couple of months to run before EOL.

-- 
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

[Bug 1815320] Re: Potential data loss in CryFS 0.9.9 (fixed in 0.9.10)

2019-04-27 Thread Sebastian Messmer
That's great, thank you :)
What queue is this? A CI service? Is it normal that the queue takes more than a 
week or did something go wrong? You uploaded it a week ago but it still says 
0.9.9 for cosmic and bionic at https://launchpad.net/ubuntu/+source/cryfs .

-- 
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

[Bug 1815320] Re: Potential data loss in CryFS 0.9.9 (fixed in 0.9.10)

2019-04-20 Thread Simon Quigley
Hello Sebastian, thanks for your work on this! I appreciate the thorough
and standards-compliant bug description on the first try. :)

I no-change backported 0.9.10-1 to Bionic and uploaded it to the queue.
I didn't backport 0.9.10-2 because it is a mipsel-related change that
really isn't appropriate for an SRU. 0.9.9-2 is equivalent to
0.9.9-1ubuntu1, so it can replace that change.

Unsubscribing the Ubuntu Sponsors Team.

** Changed in: cryfs (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: cryfs (Ubuntu Bionic)
 Assignee: (unassigned) => Simon Quigley (tsimonq2)

-- 
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

[Bug 1815320] Re: Potential data loss in CryFS 0.9.9 (fixed in 0.9.10)

2019-03-03 Thread Mathew Hodson
** Also affects: cryfs (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: cryfs (Ubuntu)
   Status: New => Fix Released

** Changed in: cryfs (Ubuntu)
   Importance: Undecided => Medium

** Changed in: cryfs (Ubuntu Bionic)
   Importance: Undecided => Medium

** Tags added: bionic cosmic

-- 
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

[Bug 1815320] Re: Potential data loss in CryFS 0.9.9 (fixed in 0.9.10)

2019-02-09 Thread Sebastian Messmer
** 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.