Too much changed in the last 3 years, it does not make sense to follow up on
this bug. Feel free to re-open if you can replicate it with current releases.

Testing pinentry-qt Version: 0.8.0.svn234-0kk1 (the changelog indicates
that the change is in) on Debian Lenny with KWin from KDE 3.

May we close this bug now?

Applied to trunk.

D116: 298_pinentry-qt-fix-1162.diff

Am Dienstag, 8. Juni 2010 12:29:40 schrieb Marc Mutz:

so I've attached the diff to current
pinentry SVN here. Works for me. Kwin/qt3 from etch for Qt3-version,
Qt-4.4.3 (self-compiled) + kwin/qt3 for Qt4-version.

The docs say on some X11 WM's, this flag will have no effect when not also
WX11BypassWM is passed, but the latter robs pinentry of it's title bar and
borders, so I left it out.

Werner, again see my tests with Kwin (default windows manager of KDE).
I believe that we should solve the issue for very common window managers.
KWin is very common for pinentry-qt3. Maybe we can ask some KDAB folks for help
on this one, should not be that hard I guess.

If you enter something on another desktop the pinentry should notice it and
return a cancel error. It all depends on the windows manager, though.

Testing pinentry Version: 0.8.0.svn231-0kk1
with window manager kwin from kdebase Version: 4:3.5.9.dfsg.1-6+lenny1.

Let me know if I shall do a 0.8.1 release.

Fixed in the current svn. At least it works for me on Debian GNU/Linux sid and
Debian GNU/kfreebsd sid. The pinentry nows sticks to the the top and you should
not be able to change this - it is in the responsibility of the WM, though. I
am using xfwm.

I can't replicate this with pinentry-qt 0.8.0 but still with the gtk2 version
with or without the Debian keyboard race fix.

Marcus, not yet so far. I would appreciate a test on your end, as I might not
get to the issue for a while. There should be enough information to reproduce
the issue.

Hi Bernhard,

many releases in the meantime thus I am pretty sure that this has been solved -
at least on the GnuPG side.

Just for completeness, there have been more fixed in dirmngr
and the symptom seems to also have happened because an http proxy
behaved
strangely.http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/crlfetch.c?root=Dirmngr&rev=323&r1=320&r2=323

Refocussing this issue on the "hang" symptom.

Sorry, typo in the URL, (there was one "kolab/" too much, but you could have
gotten to it via the main page. :) )
https://www.intevation.de/roundup/kolab/issue3583 (offline s/mime signing
without CRL for secret key gives unkown system error)

Sorry for the delay. I can not access the kolab tracker (404), has the link
changed? Errors for individual keys in a keylisting are not available in
detail, but only the invalid flag is set. When using an invalid key, a more
detailed reason may be available. There is currently no way to get more
detailed reasons about why a key in a key listing is invalid.

Sorry for the late response, only recently a new pinentry got released.
So we will test this on basis of 0.7.6.

No response - assuming that everything is fine now.

Done. (rev 5092).

Will this be backported to 1.4 as well?

No, --fix-trustdb is a hidden command and may get a new life in the future.

Thanks for the change, I will check it out.
Did you consider removing the option --fix-trustdb
if you do not intend to implement it?
I would consider removal to be good, if the warning
is all what people get in the foreseeable future.
The existance of the options assumes that there is code
to do the fixing behind it.

Fixed in svn 5087.

An admin saw this suggestion in front of a user and got annoyed
that the recommendation

"the trustdb is corrupted; please run \"gpg --fix-trustdb\".\n") );

in tdbio_invalid(void) gnupg-2.0.12 did not work.

I guess I found it. The process was simply leaking file descriptors during the
LOOKUP commands. This should explain the hangings we noticed by some folks.
The fix is in svn rev 318. It boils down to this little patch:

I have an strace log for the time before the kill, it is quite boring only
4130804 lines of
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 select(10, [9], NULL, NULL, {0, 0}) = 1 (in [9], left {0, 0})
2951 read(9, ""..., 8192) = 0
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)
2951 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR)

New log with svn rev 313 send to Werner on friday. The user had killed dirmngr.
(I am putting the internal reference in the topic.)

ping

I changed some diagnostics to better track possible problems. You may want to
try svn rev 313.

Marcus, can you please have a look at this?

Any news on this one?

Is it possible to write out a message when we hit such a timeout?
Make that timeout configurable nontheless?

The right way to delete an option is:

Because we decided that 5 minutes are reasonable value timeout value for an
intermittently slow CRL server. I can't see the actually problem with it: The
proxy should not delay or buffer the request at all. CRLs are picked up
automagically an you don't have control over what CRL server is used - if there
is a slow one and the timeout is too short you will never ever be able to use a
certificate bound to that CRL server. Better to wait than to be sorry - these
are the usual tradeoffs you have to make while defining a timeout. Note
thatthere are a couple of other timeouts in a TCP network, which you can't
control either.

What is the reason that the "last resort timeout" cannot be configured
to be faster? (Meaning below 5 minutes?)

Well you can configure it: That last resort timeout is 5 minutes plus the
configured timeout.

What can we do about this then? There should be a configuration option
to make this problem go away, right?

Thanks Werner. BH, please test.

Fixed in pinentry svn revission 190.