Hi Uli,
I suppose that the race condition assumption was a bit of a stretch - the
problem seems to occur only when not changing the default options
controlled by radio buttons *and* the default options are not first on the
list of radio buttons.
When I display the Create Request GUI window the radio options order is
random (perhaps this has triggered the bug, I don't think that the order
was random before). I want to use the default options, so I don't change
anything. From the code I understand that the default options are being set
after displaying the radio buttons, and that's where the callback kicks in,
half-way through though - it sets only the deactivated value. Afterwards I
can click the radio buttons and everything seems to work as expected.
The attached patch which prints all 'toggled' events bound to radio buttons
generated with _fill_radiobox(). When I display the Create Request window I
see the following radio buttons:
(o) 4096 ( ) 2048 ( ) 1024
(o) SHA-1 ( ) RIPEMD-160 ...
( ) DSA (o) RSA <--- this is causing the problem
My patch prints the following into console when the window is displayed:
toggle_to_var(Gtk2::RadioButton=HASH(0x1df84a0), SCALAR(0x160f830), dsa)
When I continue to sign the certificate it fails, revealing the openssl
command:
/usr/bin/openssl ca -batch -passin env:SSLPASS -notext -config
/home/matik/.TinyCA/test3/openssl.cnf -name server_ca -in
"/home/matik/.TinyCA/test3/req/aWlpOiA6IDogOnRlc3Q6IDpQTA==.pem" -days 365
-preserveDN -md dsaWithSHA1
When I check in the Keys tab I can see that the key is indeed DSA, and not
RSA.
The order of radio button controlled options is random, so sometimes the
default options end up being first in the list and the bug doesn't trigger,
hence the "sometimes" in my original report.
That said, it seems that my patch is a workaround and not a proper
solution, but it has the desired property of solving the problem for me :-).
The problem seems two-fold:
a) the options are displayed in random order
b) the toggle event is firing only once ('deactivate') on window display
Fixing b) would solve the problem, however my debugging skills and
knowledge of GUI bindings are too weak to find a proper solution. If I
could provide any more info please let me know.
Regards,
Mateusz.
2013/11/21 Christoph Ulrich Scholler <schol...@fnb.tu-darmstadt.de>
> Hi Mateusz,
>
> Mateusz Kijowski <mateusz.kijow...@gmail.com> writes:
> >> After perl and/or gtk2-perl update tyinyca started to sometimes
> >> generate certificates with options other than specified in the new
> >> certificate window.
>
> I have not been able to reproduce this issue. Can you please provide
> more details how to reproduce it? You say that you get certificates with
> options different from those you selected, but only sometimes. Does it
> depend on your inputs in the certificate generation dialog? Is it
> random?
>
> >> After some investigation it turned out that the callback bound to
> >> 'toggled' signal was firing twice (presumably one for unchecking and
> >> one for checking the radio button) resulting in a race condition.
>
> That is the normal behavior of many GUI toolkits. I can see this leading
> to race conditions only when multi-threading has gone wrong. Tinyca uses
> only one thread, which is the same thread as that where the GUI main
> loop runs.
>
> The attached test program exercises a radio button group and the
> callbacks in one thread. The test is run by starting the program, then
> toggling the radio buttons with the mouse or by pressing and holding the
> <right> (or <left>) key and, after a little playing, clicking on the
> print button. The resulting output (in the console) shows the recorded
> 'toggled' signals. In all my tests the pattern of activations and
> deactivations was absolutely regular with no deactivation signal
> processed before the corresponding activation signal.
>
>
> >> The attached patch checks if the radio button is being set to active
> >> before assigning value to certificate options. Since
> >> GUI::_fill_radiobox() seems to be generic this might result in
> >> mangling other options controlled via radio buttons as well.
>
> I doubt that your patch will mangle other radio button-controlled
> options. But before I apply it I'd like to understand why it solves your
> issue.
>
> Regards
>
> Uli
>
>
--- /usr/share/tinyca/GUI.pm.orig 2013-03-25 09:01:53.000000000 +0100
+++ /usr/share/tinyca/GUI.pm 2013-11-22 15:24:00.293117586 +0100
@@ -3098,7 +3098,10 @@
my $key = Gtk2::RadioButton->new($previous_key, $display_name);
$key->set_active(1) if(defined($$var) && $$var eq $value);
$key->signal_connect('toggled' =>
- sub{GUI::CALLBACK::toggle_to_var($key, $var, $value)});
+ sub{
+ print "toggle_to_var($key, $var, $value)\n";
+ GUI::CALLBACK::toggle_to_var($key, $var, $value)
+ });
$radiobox->add($key);
$previous_key = $key;
}
