1 |
On 22 February 2010 06:49, Mick <michaelkintzios@×××××.com> wrote: |
2 |
> On Sunday 21 February 2010 17:01:13 Willie Wong wrote: |
3 |
>> On Sun, Feb 21, 2010 at 03:32:00PM +0000, Mick wrote: |
4 |
>> > On Sunday 21 February 2010 15:08:28 Willie Wong wrote: |
5 |
>> > > On Sun, Feb 21, 2010 at 02:50:09PM +0000, Mick wrote: |
6 |
>> > > > Yesterday I updated my system and after a series of: |
7 |
>> > > > |
8 |
>> > > > revdep-rebuild --library libjpeg.so.7 |
9 |
>> > > > |
10 |
>> > > > and |
11 |
>> > > > |
12 |
>> > > > revdep-rebuild -v -i |
13 |
>> > > > |
14 |
>> > > > I thought all was good to go. Unfortunately, I now noticed that I |
15 |
>> > > > cannot open encrypted messages anymore and signing mail fails. This |
16 |
>> > > > points towards gnupg which I remerged along with all packages I |
17 |
>> > > > thought might me relevant. I haven't yet remerged openssl (will try |
18 |
>> > > > that in a minute) but I am not sure that will help. It's not just |
19 |
>> > > > smime but also openpgp that fails. |
20 |
>> > > > |
21 |
>> > > > Has anyone else noticed this and have you found any fixes for it? |
22 |
>> > > |
23 |
>> > > Just a random guess: maybe revdep-rebuild updated to a new version and |
24 |
>> > > configuration files changed? Did you look at the elogs of whatever you |
25 |
>> > > re-emerged yesterday? |
26 |
>> > |
27 |
>> > Yes and I ran dispatch-conf for a couple of changes. However, nothing |
28 |
>> > that I recall was related to encryption: |
29 |
>> > |
30 |
>> > Sat Feb 20 08:05:50 2010 >>> media-libs/jpeg-8 |
31 |
>> > Sat Feb 20 08:20:29 2010 >>> media-sound/phonon-4.3.80-r1 |
32 |
>> > Sat Feb 20 08:36:37 2010 >>> media-libs/tiff-3.9.2 |
33 |
>> > Sat Feb 20 08:39:24 2010 >>> media-libs/libquicktime-1.1.3 |
34 |
>> > Sat Feb 20 08:42:15 2010 >>> media-libs/gd-2.0.35-r1 |
35 |
>> > |
36 |
>> > Anything else I could look into? |
37 |
>> |
38 |
>> Then I am kind of out of ideas. You mentioned that you remerged gnupg: |
39 |
>> was there any warnings or logs at the end of the merge? (If you have |
40 |
>> it enabled, the logs maybe stored in /var/log/portage/elog/) |
41 |
>> |
42 |
>> You say that smime and openpgp fails, do you have the error message? |
43 |
>> It may help other people who know more about this to answer your |
44 |
>> question. |
45 |
> |
46 |
> Thanks again for your help. The problem seems to be with pinentry when gpg is |
47 |
> invoked manually: |
48 |
> |
49 |
> gpg: problem with the agent: No pinentry |
50 |
> |
51 |
> and then as a consequence: |
52 |
> |
53 |
> gpg: public key decryption failed: General error |
54 |
> gpg: decryption failed: No secret key |
55 |
> |
56 |
> However, I have remerged pinentry. :-( |
57 |
> |
58 |
> Initially, I thought this was related to updating media-libs/jpeg-8 and |
59 |
> library libjpeg.so.7, but it seems that it may be related to qt3 becoming |
60 |
> deprecated? Perhaps I should unmask app-crypt/pinentry-0.7.6 which has qt4 in |
61 |
> its USE flags and try with that? |
62 |
> |
63 |
> Meanwhile I just resync'ed and there's a load of kde-4.3.5 updates. Perhaps I |
64 |
> was cought up in some major update bonanza and that's why this broke. I'll |
65 |
> finish the update and see how it goes. |
66 |
|
67 |
This is rather debilitating ... I have now update pinentry to 0.7.6 |
68 |
and I still have the same problem. :-( |
69 |
|
70 |
I may have to restore my system from a back up just to access my |
71 |
encrypted data, which is something I'd rather not have to do after a |
72 |
mammoth kde update. |
73 |
|
74 |
The elog of pinentry shows this, but I am not sure I understand what |
75 |
it means, or if it is related to my problem. |
76 |
|
77 |
====================================== |
78 |
|
79 |
>>> Messages generated by process 10763 on 2010-02-24 07:01:34 GMT for package a |
80 |
pp-crypt/pinentry-0.7.6: |
81 |
|
82 |
LOG: postinst |
83 |
We no longer install pinentry-curses and pinentry-qt SUID root by default. |
84 |
Linux kernels >=2.6.9 support memory locking for unprivileged processes. |
85 |
The soft resource limit for memory locking specifies the limit an |
86 |
unprivileged process may lock into memory. You can also use POSIX |
87 |
capabilities to allow pinentry to lock memory. To do so activate the caps |
88 |
USE flag and add the CAP_IPC_LOCK capability to the permitted set of |
89 |
your users. |
90 |
====================================== |
91 |
|
92 |
Since invoking gpg on the CLI does not ask for a passphrase and it returns: |
93 |
|
94 |
gpg: problem with the agent: No pinentry |
95 |
|
96 |
I assume that the problem is with pinentry. Is there some other |
97 |
application involved here that I should look into? |
98 |
-- |
99 |
Regards, |
100 |
Mick |