patch - fix logic flaw, make seahorse-tool's encrypt command work
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | libcryptui |
Fix Released
|
Medium
|
||
| | libcryptui (Debian) |
Fix Released
|
Unknown
|
||
| | libcryptui (Ubuntu) |
Medium
|
Unassigned | ||
| | Xenial |
Medium
|
Unassigned | ||
Bug Description
[Impact]
The prompt recipients dialog that's called when you run seahorse-tool with --encrypt argument is broken.
Clicking on OK button does nothing, and encryption of the chosen file does not happen.
The prompt recipients dialog has been broken in this commit:
The attached debdiffs fix the logic there and makes seahorse-tool's encrypt command work again. Therefore, seahorse plugins for both Nautilus and Nemo should start working as well. Clicking on OK button works, and the file gets encrypted as it should.
So the fix should be ported to the listed stable releases. In 14.04 things haven't been broken yet.
[Test Case]
Steps to reproduce:
1. Run "seahorse-tool --encrypt some_file".
2. In the dialog that appears, choose the recipient by clicking on a checkbox.
3. Click on OK button.
4. The dialog just closes and the file doesn't get encrypted as it should.
[Regression Potential]
No regressions have been found during several months of testing. I consider the regression risk to be very low here.
| Vlad Orlov (monsta) wrote : | #1 |
| tags: | added: utopic |
| Launchpad Janitor (janitor) wrote : | #3 |
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in libcryptui (Ubuntu): | |
| status: | New → Confirmed |
| tags: | added: vivid |
| Changed in libcryptui (Debian): | |
| status: | Unknown → New |
| Changed in libcryptui (Ubuntu): | |
| importance: | Undecided → High |
| Tim (darkxst) wrote : | #4 |
The fix in the attached patch is incorrect, it is clearly breaking the api:
@symmetric: Variable in which to store if symmetric encryption is requested.
* Set to NULL to disable symmetric encryption.
possibly the logic error is actually in seahorse-nautilus, passing NULL to cryptui_
| David Beswick (dlbeswick) wrote : | #5 |
I don't think that's the case, Tim.
The version of seahorse-nautilus in utopic, 3.8.0, is calling "cryptui_
return cryptui_
So it's cryptui that is itself supplying the NULL value.
Further, the function comment you cite specifies that NULL is a valid input when symmetric encryption is not desired. The comment around the patch states "Ask for recipients if symmetric encryption was not requested or if the user didn't give a symmetric passphrase." It seems both appropriate and the intention of the code (by the comment) to pop up a key chooser dialog if the caller requests that symmetric encryption should not be used. However, if the caller ever passes a NULL then no dialog will be popped up.
It does seem like a logic error to me.
Finally, I will note that the latest version of seahorse-nautilus that I looked at in bzr does call cryptui_
| Vlad Orlov (monsta) wrote : | #6 |
Still not considered, despite the "High" importance?
| Vlad Orlov (monsta) wrote : | #7 |
| Vlad Orlov (monsta) wrote : | #8 |
| Vlad Orlov (monsta) wrote : | #9 |
[Impact]
The prompt recipients dialog that's called when you run seahorse-tool with --encrypt argument is broken.
Clicking on OK button does nothing, encryption of the chosen file does not happen.
The attached debdiffs fix the problem - clicking on OK button works, the file gets encrypted as it should.
So the fix should be ported to the listed stable releases.
[Test Case]
Steps to reproduce:
1. Run "seahorse-tool --encrypt some_file".
2. In the dialog that appears, choose the recipient by clicking on a checkbox.
3. Click on OK button.
4. The dialog just closes and the file doesn't get encrypted as it should.
[Regression Potential]
No regressions have been found during several months of testing.
I consider the regression risk to be very low here.
| tags: | added: wily |
| David Beswick (dlbeswick) wrote : | #10 |
Hi, this issue persists in wily. I think it warrants attention since two people have gone to the effort of diagnosing the issue, creating a patch and vouching for it. If there's some other way that I can help to get this resolved, then please do let me know.
At the least, upgrading the version of seahorse-nautilus would help. I can say that building and installing git-v1:
| description: | updated |
| Changed in libcryptui (Ubuntu): | |
| status: | Confirmed → Triaged |
| Mathew Hodson (mathew-hodson) wrote : | #11 |
Setting importance to Medium because this impacts a non-core application.
| Changed in libcryptui (Ubuntu): | |
| importance: | High → Medium |
| Tim (darkxst) wrote : | #12 |
I can't reproduce this Xenial and looks like Wily has the same versions, so can anyone confirm it has been fixed there? If not can probably backport the patch that fixed it.
Utopic and Vivid are both EOL now.
The logic fix itself is probably correct, but should be forwarded upstream to GNOME.
Unsubscribing ubuntu-sponsors for now
| Changed in libcryptui (Ubuntu): | |
| status: | Triaged → Incomplete |
| epictete (p-latreyte) wrote : | #13 |
The bug still exist in Xenial with Nemo File Manager pull-down menu: when choosing the Encrypt… option your're asked to choose the key to be used but then nothing happens, the file is not encrypted.
The encryption works perfectly in command line.
| epictete (p-latreyte) wrote : | #14 |
Exactly the same under Linux Mint 18 Cinnamon 3.0.7 ; with Nemo File Manager pull-down menu: when choosing the Encrypt… option your're asked to choose the key to be used but then nothing happens, the file is not encrypted.
The encryption works perfectly in command line.
| Changed in libcryptui (Debian): | |
| status: | New → Confirmed |
| Dmitry Nurislamov (nimms) wrote : | #15 |
I'm experiencing the issue in Linux Mint 18 too.
I installed the package `nemo-seahorse_
Seahorse integration to Nemo File Manager. It is based on seahorse-nautilus
and uses libcryptui internally.
Signing the files works, but I can't encrypt them. After choosing recipients
and pressing "OK" the window just closes without any messages,
leaving me with nothing. The package contains the tool called `seahorse-tool`,
which the Nemo plug-in internally uses. If I try to start it manually
from the terminal, I get the same result.
Now I'll try to explain why I think the Vlad's fix is correct.
The tool uses the `cryptui_
the function calls `cryptui_
with the `NULL` value for its `symmetric` parameter. The problem is that
the imperative code block doesn't work with `symmetric` set to `NULL`.
So look at the definition of the `keys` pointer, which the function returns:
gchar **keys = NULL;
Now look at the faulty code block:
if (symmetric != NULL && !*symmetric) {
/* ... */
keys = g_new0(gchar*, g_list_length (recipients) + 1);
for (l = recipients, i = 0; l; l = g_list_next (l), i++)
keys[i] = g_strdup (l->data);
/* ... */
}
When the `symmetric` is set to `NULL`, this block never runs, so the function
returns `NULL`, which the calling program gets and can't do anything.
Let's rewrite the condition to be clearer:
if (symmetric != NULL && *symmetric == FALSE)
`symmetric == NULL` and `*symmetric == FALSE` should mean the same,
as the comment states:
@symmetric: Variable in which to store if symmetric encryption is requested.
Set to NULL to disable symmetric encryption.
The correct condition, which the patch uses, is:
if (symmetric == NULL || *symmetric == FALSE)
So it *is* a logic flaw. The Vlad's patch fixes it.
| tags: | added: xenial yakkety |
| Changed in libcryptui (Ubuntu): | |
| status: | Incomplete → Triaged |
| Changed in libcryptui (Ubuntu Xenial): | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| Changed in libcryptui: | |
| importance: | Unknown → Medium |
| status: | Unknown → Fix Released |
| Changed in libcryptui (Debian): | |
| status: | Confirmed → Fix Released |
Nemo users who may still be effected by this bug can replace apt nemo-seahorse with seahorse-nautillus as posted in the nemo specific bug: https:/


The attachment "This patch fixes the logic in the prompt recipients dialog." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]