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

[Rob Browning <rlb@defaultvalue.org>]

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?  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.

> 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
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4