"Terminal: true" hardcodes gnome-terminal

Bug #365796 reported by Jim Campbell on 2009-04-24
18
Affects Status Importance Assigned to Milestone
eCryptfs
Medium
Unassigned
update-notifier (Ubuntu)
Medium
Michael Vogt
Karmic
Medium
Unassigned

Bug Description

This bug report is similar to LP bug #359997, but I don't believe it to be duplicate. I performed a clean installation of Xubuntu 9.04 alternate, and chose to encrypt my home directory.

Upon completing the installation, I was presented with the lightbulb icon in my panel, indicating that information was available. I clicked the icon, read the instructions, and then selected, "Run this action now." However, nothing happened after clicking on the button. A terminal window did not open, and I was not presented with an error. Perhaps the "run this action now" button is calling gnome-terminal or something that is not installed on Xubuntu, but this should examined.

Fortunately, I was able to research the issue, and I found the aforementioned bug report. Entering, "ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase" gave me the necessary prompt, and I was able to get my autogenerated strong passphrase.

Related branches

Dustin Kirkland  (kirkland) wrote :

I'll take a look at this. I need to setup a Xubuntu VM though.

Thanks for the report.

:-Dustin

Changed in ecryptfs-utils (Ubuntu):
assignee: nobody → Dustin Kirkland (kirkland)
importance: Undecided → High
Changed in ecryptfs:
importance: Undecided → High
Alvin (alvind) wrote :

This issue is also present in Kubuntu 9.04

Dustin Kirkland  (kirkland) wrote :

Confirmed. I have reproduced the problem. Looking at the code, there is no reference to gnome-terminal. The "Run" action just calls "sh ....". Looks to me like sh needs a handler in XFCE?

In any case, the text in the dialog tells the user *exactly* what they need to do, if they want to run this by hand (run ecryptfs-unwrap-passphrase).

:-Dustin

Changed in ecryptfs:
status: New → Confirmed
Changed in ecryptfs-utils (Ubuntu):
status: New → Confirmed
Changed in ecryptfs:
importance: High → Wishlist
Changed in ecryptfs-utils (Ubuntu):
importance: High → Low
Changed in ecryptfs:
importance: Wishlist → Low
Dustin Kirkland  (kirkland) wrote :

Can someone from Xubuntu help me understand what's going on here? Does Xubuntu have a handler for sh calls?

Something akin to Gnome launching gnome-terminal, or KDE launching konsole?

:-Dustin

Lionel Le Folgoc (mrpouit) wrote :

Yes, there is xfce4-terminal.

But I don't really understand. Is the code making an explicit call to gnome-terminal? Why not using x-terminal-emulator alternative then instead?

Pres-Gas (presgas) wrote :

I commented on your blog earlier. I wonder if the .sh file can be called by the alternative's "x-terminal-emulator" instead of a specific terminal emulator?

Dustin Kirkland  (kirkland) wrote :

The code is not making any explicit call to gnome-terminal.

It's calling:

Command: "sh -c 'ecryptfs-unwrap-passphrase $HOME/.ecryptfs/wrapped-passphrase 2>/dev/null && echo [Enter] && head -n1 && touch $HOME/.ecryptfs/.wrapped-passphrase.recorded '"

This is just running "sh". What is the default handler for "sh" in XFCE? I think the bug may be in XFCE itself, needing to set x-terminal-emulator for handling the "sh" program.

Changed in ecryptfs:
importance: Low → Medium
Changed in ecryptfs-utils (Ubuntu):
importance: Low → Medium
status: Confirmed → Incomplete
Changed in ecryptfs:
status: Confirmed → Incomplete
Lionel Le Folgoc (mrpouit) wrote :

Yeah, ok, I've read the complete bug report this time. But you're still writing weird things from my point of view. ;)
Sh isn't a file/mimetype, so I don't understand why there is a need for a default handler. Also, the command is starting sh, so why would someone want to start a terminal-emulator instead? Moreover, I just tried on Xfce and GNOME to run (alt+f2) "sh -c 'echo foo'", and it doesn't start a sh handler, even on GNOME, so I'm even more confused.

A more correct way might be to do something like:
x-terminal-emulator -e sh -i -c 'ecryptfs-unwrap-passphrase $HOME/.ecryptfs/wrapped-passphrase 2>/dev/null && echo [Enter] && head -n1 && touch $HOME/.ecryptfs/.wrapped-passphrase.recorded '

This would start a terminal emulator, as expected...

Pres-Gas (presgas) wrote :

Dustin,

Pardon my ignorance on this, but maybe if you can enlighten me on this, we might be able to track down KDE and XFCE equivalents or a way to make this more platform agnostic. What calls this file:
"https://bazaar.launchpad.net/~ecryptfs/ecryptfs/ecryptfs-utils/annotate/head%3A/src/desktop/ecryptfs-record-passphrase"? Also, where is it in Gnome that sets the handler for "sh"?

Dustin Kirkland  (kirkland) wrote :

pitti-

You helped create this file originally... Any suggestions on how to get this working on KDE and XFCE too? Also, there's a separate bug about making the notification translatable. Can you help with that as well?

Martin Pitt (pitti) wrote :

ecryptfs itself is just fine, it has "Terminal: true" in the update notification. The problem is in update-notifier:

   if(term != NULL && !g_ascii_strncasecmp(term, "true",-1)) {
      cmdline = g_strdup_printf("gnome-terminal -e %s",cmd);
   } else
      cmdline = g_strdup(cmd);

This should check if gnome-terminal exists, or preferably just use x-terminal-emulator instead of gnome-terminal.

Changed in ecryptfs:
status: Incomplete → Invalid
affects: ecryptfs-utils (Ubuntu) → update-notifier (Ubuntu)
Changed in update-notifier (Ubuntu):
assignee: Dustin Kirkland (kirkland) → Michael Vogt (mvo)
status: Incomplete → Triaged
summary: - Prompt to record encryption passphrase produces no response in Xubuntu
- 9.04
+ "Terminal: true" hardcodes gnome-terminal
Pres-Gas (presgas) wrote :

Martin and Dustin,

Thank you all so much to both of you for working on this and figuring out the root of the problem. Not only is this a win for desktop interop, but it allowed me to learn a bit about both of these utilities. They both rock and you both are "teh awesome" (to use the vernacular).

Martin, any ETA or possibility that this would be pushed out for Karmic? Dustin, if this does get pushed out for this release, can the dialogue show itself again? I suspect the file "$HOME/.ecryptfs/.wrapped-passphrase.recorded" is the key, am I correct?

Martin Pitt (pitti) wrote :

It's not that useful for an SRU, since this is mostly a problem when doing a fresh install (and this won't have the update yet). But if you wait long enough with clicking on the notification, it might help. Also, I assume it's a trivial one-liner patch.

Changed in update-notifier (Ubuntu Karmic):
importance: Undecided → Medium
status: New → Triaged
tags: added: iso-testing
Lionel Le Folgoc (mrpouit) wrote :

Any progress on this issue? I just experienced it yesterday on lucid... And what's blocking the proposed fix? x-terminal-emulator offers a common 'interface', so no apparent compatibility issue on this side...

Michael Vogt (mvo) wrote :

This will not be fixed for karmic anymore. But we could consider a SRU for lucid if someone steps up and creates a diff.

Changed in update-notifier (Ubuntu):
status: Triaged → In Progress
Changed in update-notifier (Ubuntu Karmic):
status: Triaged → Won't Fix
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-notifier - 0.110.4ubuntu1

---------------
update-notifier (0.110.4ubuntu1) natty; urgency=low

  * src/hooks.c:
    - use x-terminal-emulator instead of hardcoding gnome-terminal
      (LP: #365796)
 -- Michael Vogt <email address hidden> Wed, 16 Feb 2011 19:37:04 +0100

Changed in update-notifier (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers