Bug#860425: unblock: emacs24/24.5+1-9

[Niels Thykier <niels@thykier.net>]

Rob Browning:
> Niels Thykier <niels@thykier.net> writes:
> 
>> I have two comments/questions:
>>
>>  1) There is a "Maybe-Failed" FTBFS on ppc64el for emacs24.  At first
>>     glance, I don't see a reason why it should be related to these
>>     changes. However, it must be resolved for an unblock to have any
>>     effect.
> 
> Hmm, looks like it may have succeeded?

Apparently, someone get it another shot and that worked. :)

> Though given the earlier error,
> I wonder if emacs24 might now need some of the adjustments that we made
> to emacs25 to address glibc changes, i.e. #842728 (memory exhaustion
> iirc) and maybe #841551 (segfaults).  Though I haven't delved.
> 

Ok.  Is there any easy way to figure this out?  I am ready to consider
additionally targeted fixes for non-deterministic build failures.

>> Does that mean emacs 24 will try gnutls-cli first.  If that fails, then
>> with --protocols ssl3 and if that fails as well, fall back to openssl
>> s_client?
> 
> I'm not certain, but that sounds correct.
> 
>> As I understand it, ssl2 and ssl3 is not considered "secure" any more,
>> so if it the above is correctly analysed, I think we should remove the
>> latter two options and move them to the "only if explicitly requested" list.
> 
> Moreover, it's been stated that s_client should just not be used.
> Directly related I think:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766397#141
> 
> (And see Kurt's earlier message(s) in the report.)  Though in my patch
> there I hadn't removed the gnutls-cli ssl3 invocations too.
> 
> I'd wondered about proposing an unblock request for that bug next,
> assuming the fix ended up being plausible, but wasn't sure, since it's
> already been marked for deferral for stretch.
> 
> Thanks
> 

If it is just a question of moving two insecure commands from one list
(auto-try) to another (manual request) or even just removing them, then
I am quite happy to accept it for stretch.

The stretch-can-defer/stretch-ignore means we won't stall the release
for that bug, but often we are still happy to accept a targeted fix for
it. :)


Thanks,
~Niels