After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 435278 - The key properties 'trust' tab interacts strangely with gpg's trust model.
The key properties 'trust' tab interacts strangely with gpg's trust model.
Status: RESOLVED FIXED
Product: seahorse
Classification: Applications
Component: general
1.0.1
Other All
: Normal normal
: 2.20.0
Assigned To: Seahorse Maintainer
Seahorse Maintainer
Depends on:
Blocks:
 
 
Reported: 2007-05-02 18:50 UTC by Alex L. Mauer
Modified: 2008-05-02 01:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alex L. Mauer 2007-05-02 18:50:36 UTC
Please describe the problem:
When selecting the checkbox "I have checked that this key belongs to...", instead of setting the validity of the key, seahorse sets the trust level of the key.

This has some side-effects that I think are probably unintentional.  If I select that checkbox for 3 keys, and those keys then sign a 4th key, then that 4th key becomes validated.  This should not happen since according to the seahorse interface I have not indicated that I trust their signatures on other keys.

This also works in reverse: setting the trust level to marginal will select the checkbox.

Steps to reproduce:
1. Select the checkbox.
2. examine the trust level of the key.


Actual results:
The trust level is "marginal".

Expected results:
The trust level is "unknown".

Does this happen every time?
yes.

Other information:
Suggested fix:
"I have checked that this key belongs to" should local-sign the key.  Probably it should use minimal validity, but see next comment.
Then "sign key" can upgrade the signature to an exportable one.  If it's not possible to change the validity level while upgrading, then seahorse should ask for the validity during the lsign step above.
Comment 1 Fabian Zeindl 2007-07-11 15:35:20 UTC
another sideeffect is, that setting the trust level to "never" is not possible at all...
Comment 2 Fabian Zeindl 2008-01-04 12:16:09 UTC
Anything new on that? This keeps bugging me since half a year...
Comment 3 Fabian Zeindl 2008-01-19 15:21:47 UTC
I think seahorse is mixing up validity and trust at the moment.

1. The "trust" tab should IMHO list keys which are _valid_: the keys I signed myself, the keys which were signed by owners I trust etc.

2. "I have checked that this key belongs to" should sign the key.

3. Setting "I trust this key to sign other keys" should set the trust level. Maybe to marginal. Maybe the option should be renamed: "I trust the owner of this key to sign other keys: Never / Marginal / Full.

Signatures:
 I think the combinations of options between local sign, trusted sign, non-revokable sign are just utterly confusing, even for experienced users.
En plus it is nonsense to be able to sign a key while selecting "I did not check the owner". I think seahorse should always sign with a exportable, revokable signature and should also insist the user on checking the key before signing it.

A problem:
 It is technically possible to not have a private keyring, but it would be nevertheless useful to be able to set the validity of the key. As far as I know gpg cannot _set_ the validity of a key without signing it.
Comment 4 Alex L. Mauer 2008-01-19 19:21:13 UTC
I agree, and have the following to add:

1. If that is done, the "Trusted Keys" tab should be renamed to "Validated Keys"

Signatures:
I agree that the combination is confusing (yes, even as an experienced user).  Further, I never use the "trusted" or "irrevokable" signature types.  I do think that local signatures are very good, and should be on by default, to avoid "corrupting" the database with invalid trust.  There are situations, speaking for myself, where it's useful to be able to have a key that I know I trust for the limited purposes for which I use it, yet I don't necessarily want others to use that trust.  The current description ("Others may not see this signature") is not very clear though, if you don't know what it's doing.  A better one might be "Allow others to use this signature in their trust decisions" but that's kind of wordy.

On the topic of "not-at-all" checking, it is easy enough to filter out when doing signature calculations later on, so IMO not a problem.
Comment 5 Fabian Zeindl 2008-01-20 11:45:52 UTC
@Signatures:
 Makes sense to me. Maybe the option should be called "make this signature exportable at keysyncs" or something similar.

@not-at-all-checking:
 Do you mean the possibility of not having a private key? I just thought it was a problem, but it's not, cause it's not in the concept of gpg to set validity without signing a key.

Another discovery: in recent gpg version (I have 1.4.6) the question whether you checked the key before you sign it has been removed. So I guess it isn't needed in seahorse either.
Comment 6 Fabian Zeindl 2008-01-20 11:48:56 UTC
Will some developer confirm this issue, since I think it's a major design-problem in seahorse?
Comment 7 Alex L. Mauer 2008-01-21 00:59:26 UTC
It hasn't been removed in gpg, it's just been hidden by default.  The option is ask-cert-level/no-ask-cert-level.
Comment 8 Fabian Zeindl 2008-03-15 14:47:27 UTC
*bump* Any news about this?
Comment 9 Fabian Zeindl 2008-03-29 12:55:33 UTC
I think this bug reports WRONG behaviour in seahorse when dealing openPGP. This can lead to confusion and wrong usage of openPGP. I can't understand why no-one in about a year's time can confirm this.
Comment 10 Fabian Zeindl 2008-04-26 12:43:06 UTC
2 month later. A security critical application in Gnome (and Ubuntu) still has a bug no-one cares about.
I don't want to nag around, but I don't have any other possibilities? Learning C is unfortunately no option for me at the moment, and in my opinion people who can't code and therefore provide patches should have the same rights and possibilities to report bugs (and be listened).

Any suggestions how I can help you fixing this issue without learning C?
Comment 11 Adam Schreiber 2008-04-26 15:43:08 UTC
Fabian,

It's not a "don't care" position, it's a lack of time problem.  I'm not employed to work on Free Software and I don't believe Stef is either.
Comment 12 Fabian Zeindl 2008-04-26 16:00:30 UTC
I fully understand a "don't have time"-response.
What I don't understand is when there is _no_ response at all for month.
I work at and file bugs for several free software applications and recall situations where the reason that no-one looks at your bug is that nobody is interested in the problem.

I find situations extremely frustrating because I simply don't know, whether it's not a big problem, whether nobody has time to work on it or I simply wrote nonsense in the report.

So thanks for the update, that was the reaction I intended.
Comment 13 Adam Schreiber 2008-05-02 01:45:01 UTC
There are some outstanding bugs not related to this issue that still involve the 'trust' tab.  I'll file them.  Issues related to local sigs or wording of tab labels should be in separate bugs, I will not file those.

2008-05-01  Adam Schreiber  <sadam@clemson.edu>

    * src/seahorse-key-properties.c:
    * src/seahorse-pgp-public-key-properties.glade: Change "trust model" used
    to match GPG.  Fixes bug #435278