[Pkg-openssl-devel] Bug#804487: rebuilding openssl_1.0.2d-1 exhibits the same issue

[Chris Knadle]

Kurt Roeckx:
> On Sun, Nov 15, 2015 at 08:10:50PM +0000, Chris Knadle wrote:
>> Kurt Roeckx:
>>> On Sun, Nov 15, 2015 at 08:00:57AM +0000, Chris Knadle wrote:
>>>> I'd like to try building openssl_1.0.2d-1 with gcc-4.9 to see if the
>>>> behavior change was due to gcc-5 -- if there's an easy way to specify that
>>>> please let me know.
>>>
>>> If you edit the Configure file, for instance the debian-amd64
>>> line, it has the compiler for that target in it.
>>>
>>> Note that the debian-amd64 line comes from the
>>> debian-targets.patch.
>>
>> Thanks, that was helpful.
>>
>> ... Huh.  Rebuilding openssl_1.0.2d-1 with gcc-4.9 and using it to build
>> mumble_1.2.10-2 with g++-5, the result works fine.  So it seems it was
>> simply the switch to gcc-5 that changed this behavior.
>>
>> On the one hand one could call this a regression since it breaks something
>> that worked before, and on the other hand it caught a bug in the code in
>> mumble that nobody knew it had.  This therefore leaves a question as to
>> whether to consider this is a bug or a feature of gcc-5.  Probably both.
> 
> I'm not sure what to make of this. I find it strange the a change
> in the compiler can have something like that as effect.

Ugh.  No, unfortunately the gcc-5 conclusion is incorrect -- it's a false
negative followed by a positive because I didn't understand how the mumble
client behaves in these broken/fixed conditions.

When mumble is started in the "broken" state, it can't find the user's SSL
key and opens a dialog box to either create a new one or to import an
existing one.  Pressing "Cancel", one would expect no action would be taken
but instead it overwrites the user's automatically saved key in
~/Documents/MumbleAutomaticCertificateBackup.p12 with an emtpy file.  :(
Data loss.

Then when mumble is started in the "fixed" state, it still can't find the
user's SSL key and does the same thing, but pressing "Cancel" unexpectedly
causes a new and /validly populated/ SSL key to be stored in that file --
but where the dialog box came up, it /looks/ like mumble is still broken.
Trying to load the automatically saved backup SSL key doesn't change this,
because when mumble was "broken" it was overwritten by an empty file -- so
that option acts broken too.  This is the "false negative".

On the /next/ start, mumble finds the backed-up SSL key and uses it without
prompting! ... no SSL dialog box comes up.  :-o  This is the "positive"
which is misleading.

So not knowing this, I had built mumble three times with 3 different
versions of openssl and had three different results:
  1. built with openssl_1.0.2d-3, mumble overwrites with an empty SSL key
  2. built with openssl_1.0.2d-1 with gcc-5 -- mumble acts broken but isn't
  3. built with openssl_1.0.2d-1 with gcc-4.9 -- mumble acts fixed

So... yeah double-checking again this still seems openssl_1.0.2d-3 related
unfortunately.  Now I know the broken/fixed behavior and will be able to
test this more rigorously.  Sorry for the unintentional false report.

   -- Chris

-- 
Chris Knadle
Chris.Knadle at coredump.us