F-Spot deletes temporary image files too early when sending mails

[Johannes Weiß]

Binary package hint: f-spot

How to reproduce (thunderbird configured as primary email client, up to date ubuntu 7.04)
- In F-Spot: File -> send email
- Now, f-spot creates a temporary jpg-file in /tmp and opens thunderbird. But when you switch back to f-spot and change the perspective (e.g. double-click on another image), f-spot deletes the temporary file and sending mail is not possible anymore...

TEST CASE:
1. Monitor the content of /tmp/ with the command:
    $ watch -n1 "ls /tmp/tmp*.tmp/"
2. In the f-spot's image browser, select a picture
3. Select menu Photo / Send by Mail ...
4. In the dialog, click on 'Create Mail'
=> The default mail client opens with the picture in attachment
5. At the same time a temporary directory (e.g /tmp/tmp3992b325.tmp/) is created with the picture attached in it.
6. Wait for 30s and check that the temporary file is still there

VERIFICATION SUCCEEDED:
- The tmp file is still there after 30s.

ProblemType: Bug
Architecture: i386
Date: Sat May 5 21:54:20 2007
DistroRelease: Ubuntu 7.04
ExecutablePath: /usr/bin/gnome-panel
Package: gnome-panel 1:2.18.1-0ubuntu3.1
PackageArchitecture: i386
ProcCmdline: gnome-panel --sm-client-id default1
ProcCwd: /home/maria
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-panel
Uname: Linux maria-laptop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

[Pedro Villavicencio (pedro)]

Is this still an issue with f-spot 0.4 from Gutsy?

[Pedro Villavicencio (pedro)]

Closing this bug for now, feel free to re open it if you can reproduce it with Gutsy Gibbon, thanks.

[wastrel (wastrel)]

Reproduced in Gutsy and also in Hardy using Thunderbird as the mail client. (Thunderbird is set as "mail reader" in system > preferences > preferred applications)

F-spot creates an image directory in /tmp and puts image files in there. If I sent the message quickly, the image is still there and the mail goes out. If I take the time to compose a message, the images disappear and I can't send the email. I haven't been switching back to f-spot to manipulate the photos like the original submitter, I've just been typing emails.

Here's an strace of this happening (is this useful at all?)

The temp directory created is /tmp/tmp7af80db9.tmp/ you can see 3 images created in that directory and subsequently they're unlinked... I was still typing the email!

[wastrel (wastrel)]

setting status to "confirmed"

[Maxxer (lorenzo-milesi)]

This is explained in the usermanual, under the Send email section: there's a timeout after which the temporary pictures are deleted. The default value is 30 seconds, but can be increased at wish.
The gconf key is /apps/f-spot/export/email/delete_timeout_seconds

[Maia Everett (linneris)]

In this case, may I close this bug?

[ricardisimo (ricardisimo)]

I'm having this issue under Intrepid. What do I do with the above information: "The gconf key is /apps/f-spot/export/email/delete_timeout_seconds"? Thanks in advance for your help.

[ricardisimo (ricardisimo)]

Oh... OK, I found it. But how do I edit it?

[ricardisimo (ricardisimo)]

gksudo gedit... Got it. Good.

[swulf (swulf)]

This 'feature' affected me too. BTW, a convenient way to edit the 'gconf key' is to invoke 'gconf-editor' from a terminal window. This gives you a nice GUI to use to edit the F-Spot key.

[swulf (swulf)]

Even changing this value doesn't solve the problem. It is very strange, so much so I am probably going to file a separate bug to describe it.

[swulf (swulf)]

This bug is still in issue in Ubuntu 8.10 (Ibex) and with F-Spot (f-spot 0.5.0.3). I am not opening another bug report as it is basically the same issue as reported in this one.

The temporary folder F-Spot creates (in /tmp in my case) disappears automatically after a short while. When Thunderbird comes to look for it to send the mail, it fails as it no longer exists. This makes it practically impossible to send an image as email via Thunderbird using this F-Spot feature.

Further, using the Configuration Editor 2.24.1 for gconf shows that there is no '/apps/f-spot/export/email/delete_timeout_seconds' key present by default. Configuration Editor shows '/apps/f-spot/export/email' contains only the keys 'auto_rotate' and 'size'. Should this key be created manually?

[Brian O'Keefe (okeefe)]

Same issue here. No /delete_timeout_seconds key to edit. Any answers here?

[Paul Crawford (psc-sat)]

I have exactly the same problem as described by swulf wrote on 2009-01-17. How to fix it, with no gconf key present?

And just who thought you could compse and send an email in 30 seconds!? Please step foward and explain...

[Onno Benschop (onno-itmaze)]

From a usability perspective we cannot expect a user to launch the configuration editor to change this default value. I'll have a look at how it's packaged and see if I can come up with a better default value, say 10 minutes.

[Brian O'Keefe (okeefe)]

That would be great Onno. I've been waiting for a fix. Thanks

[swulf (swulf)]

Same problem still exists in current Karmic Beta (as of 20 October 2009 update).

[Pedro Villavicencio (pedro)]

I've sent this upstream at: https://bugzilla.gnome.org/show_bug.cgi?id=601711

[takayuki (lawtonpaul)]

same bug here. thunderbird times out after 30 seconds. in 9.04 gconf doesn't show the /delete_timeout_seconds key.

wife tried to send some pictures, but couldn't. then said she's just gonna do it on the mac. aw geesh... but honey, i can fix it... too late.

[Brian O'Keefe (okeefe)]

Great! Where's the fix?

[Sebastien Bacher (seb128)]

the fix is in upstream git

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

This should be fixed in Ubuntu 10.10. Thanks for reporting.

[Paul Crawford (psc-sat)]

Will this fix be included in the 10.04 version? It looks like a simple thing to back-port and some folks on 10.04 as "LTS" could be facing it for some years...

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

The commit is at http://git.gnome.org/browse/f-spot/commit/?id=4641e0b5183778dabcbaa37fce6d3c82dfd1a106 and is does not look that complex, so it may qualify for a stable-release-update (https://wiki.ubuntu.com/StableReleaseUpdates).

I quickly made a debdiff and if you are interested, you should try getting it uploaded to Ubuntu.

[Sebastien Bacher (seb128)]

thank you for the work on the issue, lucid should get the 0.6.2 update though which would have the change for the issue too

[Brian O'Keefe (okeefe)]

I'm running Karmic 64bit and tried the patch as per the wiki instructions on applying patches and got this at the patch step:

ubuntu@ubuntu-laptop:/tmp/f-spot-0.6.1.5$ patch -p1 < ../f-spot_0.6.1.5-2ubuntu7.debdiff
patching file debian/changelog
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
patching file debian/patches/series
patching file debian/patches/git_dont_delete_emailed_files_after_a_fixed_time-out.patch

Is there a fix for the patch?

[Paul Crawford (psc-sat)]

Brian, what was in the reject log file?

Martin/Sebastian, just to add that, while wanting this ported to 10.04, think it might be best not to port it to 9.10 partly due to bug #478392 but also that it is not a LTS version.

[Brian O'Keefe (okeefe)]

Well, all the Lucid stuff and I'm running Karmic.....Is there a way to apply the patch in Karmic?

***************
*** 1,3 ****
  f-spot (0.6.1.5-2ubuntu6) lucid; urgency=low

    * debian/patches/ubuntu_add_save_and_undo.patch:
--- 1,10 ----
+ f-spot (0.6.1.5-2ubuntu7) lucid; urgency=low
+
+ * debian/patches/git_dont_delete_emailed_files_after_a_fixed_time-out.patch:
+ + Leave it up to the os to clear emailed files in /tmp/ (LP: #112684)
+
+ -- Martin Mai <email address hidden> Mon, 24 May 2010 19:26:49 +0200
+
  f-spot (0.6.1.5-2ubuntu6) lucid; urgency=low

    * debian/patches/ubuntu_add_save_and_undo.patch:

[Paul Crawford (psc-sat)]

Brian, if you delete the first 14 lines of the patch it applies in 9.10 (my home PC just now), but my attempt at building the unpatched f-spot resulted in a program that did not quite work.

[Paul Crawford (psc-sat)]

Nope, deleting lines stops error message, but did not actually patch.

[Brian O'Keefe (okeefe)]

I deleted the lines and got a bunch of successful patches but this at the end:

Applying patch git_dont_delete_emailed_files_after_a_fixed_time-out.patch
patching file src/Preferences.cs
Hunk #2 succeeded at 158 (offset -5 lines).
patching file src/SendEmail.cs
Hunk #2 succeeded at 303 with fuzz 2.
Hunk #3 succeeded at 328 with fuzz 1 (offset -3 lines).
patching file src/Preferences.cs
Hunk #1 FAILED at 61.
Hunk #2 FAILED at 163.
2 out of 2 hunks FAILED -- rejects in file src/Preferences.cs
patching file src/SendEmail.cs
Hunk #1 FAILED at 203.
Hunk #2 FAILED at 303.
Hunk #3 FAILED at 331.
3 out of 3 hunks FAILED -- rejects in file src/SendEmail.cs
Patch git_dont_delete_emailed_files_after_a_fixed_time-out.patch does not apply (enforce with -f)
dh_quilt_patch: quilt --quiltrc /dev/null push -a || test $? = 2 returned exit code 1
make: *** [build] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1334:
dpkg-buildpackage -rfakeroot -D -us -uc failed

and these:

[Brian O'Keefe (okeefe)]

Missed one file attached here

[Paul Crawford (psc-sat)]

I got mine working by using these steps:

mkdir /tmp/f-spot
./configure --prefix=/tmp/f-spot --disable-scrollkeeper
make
make install

I then tried to make the 9.10 version by manually applying the changes and then creating the debdiff file. It seems to work, but not quite as anticipated. In particular, I find that:
(1) There is no 30 second time-out now, as expected.
(2) Closing F-spot deleted the temp file, presumably due to the way it is created using System.IO.Path.GetTempFileName() but I don't know enough to say this is the case. Killing the F-spot process results in the temp file remaining (as expected).
(3) If you attempt to create a 2nd email before completing the first, it has removed the first one's temp file. This was NOT expected!

[Paul Crawford (psc-sat)]

Looking back to the original complaint, this has not been fixed. The "change of perspective" acts like opening a 2nd email and removes the temp files. I suspect this is some automatic clean-up associated with the temp file name creation, but as I just mentioned, I don't known much about .net/mono things to say for sure.
What has been fixed is the time-out when composing the email.

[Paul Crawford (psc-sat)]

Nope, I am talking nonsense! What I was seeing was a file such as /tmp/tmp1b005b6b.tmp..jpg that was being removed, but of course the attached files are in directories such as /tmp/tmp15e7b6a9.tmp/dcp_1144.jpg which are now left to the OS to clean up.
So it works, panic over :)

[Brian O'Keefe (okeefe)]

Is your patch a new one Paul? the process seems to complex for my skills in any case.

[Paul Crawford (psc-sat)]

No, it is the same changes, but made on a 9.10 system's files and recreated as a patch. To build a version to test, you need to do something like this (assuming you have not got this far already):

mkdir /tmp/f-spot
mkdir ~/f-spot-build
cd ~/f-spot-build
sudo apt-get build-dep f-spot
apt-get source f-spot
cd f-spot-0.6.1.5
./configure --prefix=/tmp/f-spot --disable-scrollkeeper
make
make install

At this point you should have a working version of the unpatched F-spot in the temporary installation directory, and you can test it with:

cd /tmp/f-spot/bin
./f-spot

Check it works, and has the usual problem. Then go back and fix it with:

cd ~/f-spot-build/f-spot-0.6.1.5
patch -p1 < ../test.debdiff
make
make install

(assuming you saved my patch in ~/f-spot-build) Then test the patched version again with this:

cd /tmp/f-spot/bin
./f-spot

If it is all happy and you like it, then re-name the /usr/lib/f-spot/f-spot.exe file and copy your built version to that directory, then change it to be root owned, something like:

cd /usr/lib/f-spot
sudo mv f-spot.exe f-spot.exe.original
sudo cp /tmp/f-spot/bin/f-spot.exe .
sudo chown root:root f-spot.exe

Hopefully that will work (not tried last steps to install, on work PC which is 10.04 just now) Note that the /tmp/f-spot test location I used here will normally be deleted on reboot, so you might want to consider putting it elsewhere if you are planning on a lot of testing, etc. You can re-create the directory and re-populate it with 'make install' as needed though.

[Brian O'Keefe (okeefe)]

Hmm, no ./configure file but a configure.ac. I can run autoconf and auto make but will that generate a configure file that I can add your arguments to?

[Brian O'Keefe (okeefe)]

I ran autoconf and automake and then:

./configure --prefix=/tmp/f-spot --disable-scrollkeeper
configure: WARNING: unrecognized options: --disable-scrollkeeper
./configure: line 2073: syntax error near unexpected token `config.h'
./configure: line 2073: `AM_CONFIG_HEADER(config.h)'

[Sebastien Bacher (seb128)]

could you move discussions about how to apply a patch out of the bug tracker, the bug noise is already high and having discussion there make people doing the work stop reading bug emails, the discussions should be focussed on Ubuntu issues and on how to solve those in Ubuntu. Note that the change is somewhat has privacy concern since it lets photo in the system tmp dir which would be available to any other user on the system until the next reboot, not sure we want to backport a such change in a stable version

[Paul Crawford (psc-sat)]

Apologies for the discussion, will keep them in future to the forums.

The issue about photo persisting is a question of magnitude, as they are open already for a short time, so this is not a new break in security/privacy, but making it a little less. Those needing the patch (e.g. Thunderbird) would otherwise have to set a long time-out, leading to the same sort of exposure.

However, the System.IO.Directory.CreateDirectory() used to create the /tmp directories can, I believe, take a security descriptor as well. I don't know how this works in the Windows/LINUX cross over, but if we could chmod 700 the resulting directories they would be safe from reading by others, and as /tmp is normally created with the 'sticky bit' set, others cannot modify or delete your won directories.

How much it matters is debatable, for most it is probably a single-user machine, or family, and the default umask allows others to read your files/photos unless you specifically set permissions to block them. But setting the temp directories permissions correctly would be a good point in principle anyway.

[Paul Crawford (psc-sat)]

Just checked, and find that the /tmp directory is 755 permissions as I mentioned, but the enclosed files are 600 permissions, so on my Ubuntu 10.04 box another user cannot actually read my F-spot created files.

This is better than the default 755/644 permissions on directories/files normally used!

So for Ubuntu users I don't see the persistent-until-reboot temp files as a security or privacy issue of any special note.

[Brian O'Keefe (okeefe)]

Any chance of backporting the fix to Karmic? I guess I don't understand why when someone posts a patch for a bug that that is off topic for discussion. Aren't we trying to get the patch to work to fix the bug?
I will respect the moderators wishes however....

[Sebastien Bacher (seb128)]

is there anybody still running karmic when there is a stabler version which is a lts available now?

[Brian O'Keefe (okeefe)]

Well, I am, obviously. I love Ubuntu but have learned that it is never a bad idea to wait a while to upgrade since I have about a 50% success rate on upgrades and this is my work machine. I can't afford any snafus. It's really no big deal as i've learned to just not use this f-spot feature though a fix was a wonderful concept. If it doesn't work in Karmic then it doesn't

[Didier Roche-Tolomelli (didrocks)]

The patch f-spot_0.6.1.5-2ubuntu7.debdiff doesn't fixed the use case as described by Paul above (https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/112684/comments/36). I've applied f-spot_0.6.1.5-2ubuntu7.debdiff and even with this upstream git fix, if you double click an another photo, the temp file is removed
What has been fixed is indeed the time-out when composing the email. Maybe I'll be worth uploading this fix and open another bug (and upstream one) stating clearly the issue again when double clicking an another photo?

[Didier Roche-Tolomelli (didrocks)]

Pushed to -proposed:

f-spot (0.6.1.5-2ubuntu7) lucid-proposed; urgency=low

  [ Martin Mai ]
  * debian/patches/git_dont_delete_emailed_files_after_a_fixed_time-out.patch:
    + Leave it up to the os to clear emailed files in /tmp/ (LP: #112684)

  [ Didier Roche ]
  * debian/patches/ubuntu_only_update_timestamp_of_unprotected_versions.patch:
    - deleted as it has some corner cases
  * add git_never_touch_photo_timestamps.patch to fix timestamp incorrectly
    imported (LP: #175191)

Test Case:
 - install the version from proposed
 - click on an image
   * try to send a photo attached to an email with file -> send
   * click on create to fire up thunderbird
   * come back to f-spot, and click on another photo
   * then, switch to thunderbird and send the email
 - do subsequent imports and see that the metadata (import date) isn't touched

[Colin Watson (cjwatson)]

Accepted f-spot into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[swulf (swulf)]

I downloaded the f-spot package from lucid-proposed this morning. I tried to send two email messages containing images from Thunderbird; one containing multiple images, the other just one. In both cases Thunderbird generated and sent email with no attachments at all.

So it seems not to work.

[Paul Crawford (psc-sat)]

I tried the 'lucid proposed' today and it seems to work fine. I could prepare several emails, some single image attached, other multiple images, and with double clicking on the 'brose' set to show it larger, etc, and all went OK.

In reply to #48 Didier, did you mistake the file /tmp/<random>.jpg with the /tmp/<random>/<filentame>.jpg that is actually attached?

In reply to #52 swulf, are you sure the 'default application' options for selecting thunderbird are correct?

This is possibly another separate bug, but I think on migrating my system from 8.10 to 9.10/10.04 it changed System -> Preferences -> Preferred Applications -> Internet -> Mail Reader to some custom setting, and I had to re-select the 'Thunderbird' option as the default client for it to provide the correct command line to successfully attach the files.

[Didier Roche-Tolomelli (didrocks)]

@paul: right, the mistake was there, and that's why I delayed the upload. The first one is used for preview and cropping.

[Jean-Baptiste Lallement (jibel)]

SRU Verification for Lucid:

I have reproduced the problem with f-spot= 0.6.1.5-2ubuntu6 and have verified that the version of
f-spot 0.6.1.5-2ubuntu7 in -proposed fixes the issue.
My only comment is that the temporary files are lying in /tmp forever and a good practice would have been to cleanup those files at f-spot shutdown.

Marking as verification-done

[Launchpad Janitor (janitor)]

This bug was fixed in the package f-spot - 0.6.1.5-2ubuntu7

---------------
f-spot (0.6.1.5-2ubuntu7) lucid-proposed; urgency=low

  [ Martin Mai ]
  * debian/patches/git_dont_delete_emailed_files_after_a_fixed_time-out.patch:
    + Leave it up to the os to clear emailed files in /tmp/ (LP: #112684)

  [ Didier Roche ]
  * debian/patches/ubuntu_only_update_timestamp_of_unprotected_versions.patch:
    - deleted as it has some corner cases
  * add git_never_touch_photo_timestamps.patch to fix timestamp incorrectly
    imported (LP: #175191)
 -- Didier Roche <email address hidden> Wed, 09 Jun 2010 10:43:14 +0200