Bug #9970
Seahorse may segfault during key synchronization
0%
Description
While working on Bug #9095 (amongst other tickets) I found that if there’s a communication failure with the keyserver during key synchronization, Seahorse may abort with a segfault. I have not yet seen this problem when fetching keys.
I don’t know if there’s an upstream bug for this.
Subtasks
Related issues
|
Related to Tails - |
Resolved | 2015-07-22 | 2016-01-15 |
|
Related to Tails - |
Rejected | 2015-11-06 | |
|
Related to Tails - |
Resolved | 2015-05-05 |
History
#1 Updated by kytv 2015-08-11 07:59:08
- blocks
Bug #9095: Seahorse tests lack robustness added
#2 Updated by kytv 2015-08-11 07:59:42
- Starter set to No
#3 Updated by kytv 2015-08-11 08:01:27
- related to
Bug #9791: Update torified_gnupg feature for Jessie added
#4 Updated by intrigeri 2015-08-11 08:10:29
- Assignee set to kytv
- QA Check set to Info Needed
> I don’t know if there’s an upstream bug for this.
Can this be reproduced without torsocks?
#5 Updated by kytv 2015-09-28 05:42:47
- Assignee deleted (
kytv) - QA Check deleted (
Info Needed)
intrigeri wrote:
> > I don’t know if there’s an upstream bug for this.
>
> Can this be reproduced without torsocks?
I’ve never had problems with any keyserver operations when not going over Tor, whether with Seahorse, Enigmail, gpg, gpg2, etc. It’s entirely possible that Seahorse’s keysyncing just doesn’t recover well with network errors, independent of Tor or torsocks.
#6 Updated by kytv 2015-11-09 19:23:22
Still a problem in Jessie. :(
╰$ scripts/vm-execute 'journalctl -l |grep seg'
Return status: 0
STDOUT:
Nov 10 03:20:51 amnesia kernel: seahorse[6095]: segfault at 0 ip 000000000807879b sp 00000000ffb599f4 error 4 in seahorse[8048000+e1000]
STDERR:#7 Updated by kytv 2015-11-10 18:44:06
- Status changed from New to Confirmed
I set up a Stretch VM for testing and I cannot reproduce the segfault.
In Tails it’s pretty simple (in both Wheezy and Jessie):
- enable key synchronization
- unplug the network
- initiate a key sync.
You’ll see an error (Cannot connect to keyserver, or the like). After you click the close button Seahorse will abort with a segfault.
#8 Updated by kytv 2015-11-11 02:19:12
I forgot to mention: I tested both with torsocks and without torsocks and I could not reproduce the segfault.
#9 Updated by intrigeri 2015-11-11 03:46:12
So I guess that next step would be to reproduce in Tails/Stretch?
#10 Updated by intrigeri 2015-12-05 13:31:01
kytv: you marked this ticket as blocking Bug #9095, and later you submitted a branch that supposedly fixes Bug #9095. So it seems the Redmine tickets semantics is somewhat wrong. I’ll let you fix this or ask me for help if you have a hard time translating your understanding of the situation into Redmine-speak :)
#11 Updated by intrigeri 2015-12-07 11:50:47
- blocked by deleted (
Bug #9095: Seahorse tests lack robustness
#12 Updated by intrigeri 2015-12-07 11:51:03
(Removed that ticket relationship.)
#13 Updated by intrigeri 2015-12-07 11:51:30
- related to
Bug #10500: Monitor failure modes of Seahorse added
#14 Updated by intrigeri 2015-12-07 11:51:49
- related to
Bug #9095: Seahorse tests lack robustness added
#15 Updated by kytv 2015-12-07 12:08:28
intrigeri wrote:
> (Removed that ticket relationship.)
I was too slow at getting to it. :(
#16 Updated by kytv 2015-12-07 12:11:06
intrigeri wrote:
> kytv: you marked this ticket as blocking Bug #9095, and later you submitted a branch that supposedly fixes Bug #9095. So it seems the Redmine tickets semantics is somewhat wrong. I’ll let you fix this or ask me for help if you have a hard time translating your understanding of the situation into Redmine-speak :)
It was valid (I think) before deciding we could restart Seahorse when it segfautled, but the relationship should have been changed when Bug #9095 and its Jessie counterpart were updated
#17 Updated by Anonymous 2017-06-29 13:25:24
- Status changed from Confirmed to Rejected
As this did not seem to be the case in Stretch during testing, I’m now closing this ticket.