evolution causes gpg stale locks

[Robert Collins]

When changing from one message to another in the mail view, and the first one is gpg signed, evolution will [sometimes] kill gpg too abruptly, leaving a stale lock.

This seems to occur when the 'verifying message (0% complete)' message is in the status bar.

You can tell this has occured by running gpg --edit-key anykeyhere.

As shown here:
$ gpg --edit-key robertc

gpg: checking the trustdb
gpg: waiting for lock (held by 21748 - probably dead) ...
gpg: waiting for lock (held by 21748 - probably dead) ...

gpg: Interrupt caught ... exiting

I dont know if this is a security bug, buts its certainly problematic: I appear to have lost by public keyring twice in some sort of interaction with this.

[Robert Collins (lifeless)]

Oh, I should mention that there is no process 21748, nor any other gpg processes running.

[Dennis Kaarsemaker (dennis)]

Only twice? I lost mine more often but never got any clue on why it
would get lost. Your analyisis helps

 status Confirmed

[Sebastien Bacher (seb128)]

Do you still get the issue with dapper or edgy?

[Dennis Kaarsemaker (dennis)]

On di, 2006-09-26 at 09:05 +0000, Sebastien Bacher wrote:
> Do you still get the issue with dapper or edgy?
>
> ** Changed in: evolution (Ubuntu)
> Assignee: (unassigned) => Ubuntu Desktop Bugs
> Status: Confirmed => Needs Info

Definitely yes with Dapper, not yet with edgy but I've been very
careful.
--
Dennis K.

Time is an illusion, lunchtime doubly so.

[Robert Collins (lifeless)]

On Tue, 2006-09-26 at 23:21 +0000, Dennis Kaarsemaker wrote:
> On di, 2006-09-26 at 09:05 +0000, Sebastien Bacher wrote:
> > Do you still get the issue with dapper or edgy?
> >
> > ** Changed in: evolution (Ubuntu)
> > Assignee: (unassigned) => Ubuntu Desktop Bugs
> > Status: Confirmed => Needs Info
>
> Definitely yes with Dapper, not yet with edgy but I've been very
> careful.

It still bits me from time to time on dapper, I dont think the frequency
has changed since the bug report. I dont have edgy at the moment : the
blood was too much for me.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Daniel Holbach (dholbach)]

We are closing this bug report as it lacks the information, which was described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and don't hesitate to submit bug reports in the future.

[Robert Collins (lifeless)]

I'm sorry, what is the requested information? If its 'does it still happen', then the answer is yes, I had it happen last week.

[Robert Collins (lifeless)]

Just to note, this is still happening. Please advise what information you are requesting.

[Robert Collins (lifeless)]

putting this back to confirmed, because it has been comfirmed

[Sebastien Bacher (seb128)]

I've forwarded the bug upstream: http://bugzilla.gnome.org/show_bug.cgi?id=418502

[Pedro Fragoso (ember)]

I've had the same bug, and about an hour of looking and trying figure where's that number and what's locking gpg... I found that the numbers held actually are the .lock files on ~/.gnupg/ .

I still don't understand why this happen but the workaround i can find right now and worked for me is really to erase the *.lock .

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

You you check if this is still an issue with the latest version of Ubuntu? Thanks in advance.

[Robert Collins (lifeless)]

 status triaged

happened yesterday

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Robert, i guess you wanted to set the status of the package in ubuntu to "triaged" and not the upstream bug. I have posted upstream that there is sttill someone suffering from this bug.

[Robert Collins (lifeless)]

I did thanks, hmm, I suspect I should file a malone bug about the
selection of task there.

-Rob

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

No problem. Upstream wants to know your evolution version. Can you please either post it here or there? Thanks.

[Robert Collins (lifeless)]

2.27.4

[Kees Cook (kees)]

gpg spawns a background process to update the trustdb at some very regular time. I suspect this may be what's going on. I noticed this when using gpg through mutt in that mutt would wait a very long time once in a while. I wonder if evolution is killing it? Robert, does adding this to your .gnupg/options file make it go away?

no-auto-check-trustdb

With this option, you need to run the trust checker once in a while, or gpg gets mad. I run this once a day from cron:

37 5 * * * gpg --check-trustdb 2>&1 | egrep -v '(depth: | needed,|next trustdb check)'

[Pedro Villavicencio (pedro)]

on the upstream bts the developers said that this bug is fixed on 2.30 which is going to land in Ubuntu Maverick

[Omer Akram (om26er)]

evolution 2.30 is in Maverick now