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 [email protected]
