Bug#954089: libplack-perl: Please verify server identity via SSL

[Dominic Hargreaves]

Hello everyone, I just caught up with this. (Side note - please don't
assume I will see a message sent to a random pkg-perl bug report[1].)

On Sun, May 17, 2020 at 06:39:34PM +0300, Damyan Ivanov wrote:
> -=| gregor herrmann, 15.05.2020 21:14:35 +0200 |=-
> > On Thu, 19 Mar 2020 14:39:13 +0200, Damyan Ivanov wrote:
> > 
> > > > > But to fully measure the impact, it would be nice to have the number 
> > > > > of failing packages built with a patched HTTP::Tiny.
> > > > I have one small concern: As the change is about checking remote SSL
> > > > certs, and tests don't/can't/must not call out to the internet, is it
> > > > possible that we won't really catch all potential issues?
> > > Noted. The test rebuilds should be done without the usual isolation 
> > > from the Internet.
> > > I guess a closer inspection of the affected packages is needed.
> > 
> > Hi Dam and all,
> > 
> > did you or anyone else get to look into this rebuild effort?
> 
> I haven't. I am still at the stage of "(re-)invent an easy way to 
> rebuild a list of packages with a crafted chroot". I don't see this 
> changing soon, so please Dom, anybody, feel free to take the job.
> 
> > If not, Dom said that he could also try the rebuilds on
> > perl.debian.net.
> > 
> > Notes:
> > - HTTP::Tiny is in perl core and in libhttp-tiny-perl;
> > - The required change looks like a one-character-patch:
> >   lib/HTTP/Tiny.pm:        verify_SSL   => $args{verify_SSL} || $args{verify_ssl} || 0, # no verification by default
> > - The tests should be run with internet enabled as much as possible.

I am happy to do this, but I want to add a large caution: I do not
think that a clean bill of health from rebuild testing by itself
will allow us to draw any meaningful conclusions. It'd tell us that 
the unit tests were correctly disabling SSL verification in their test
suites, or their test suites don't test SSL-related functionality, or
their test suites (inappropriately) rely on external servers with
correct SSL setups.

But what's much more important here, surely, is what effect such a
change will have on our users in the real world, who will be using
this module to talk to the internet, and not to mention their own
internal services. I don't really see a way to know the scale of
breakage this will cause without trying it and seeing how much noise
there is from our (unstable) users.

Note that this is not a reason to avoid making the change. I just want
to make sure we're going into this with our eyes open.

Cheers
Dominic

[1] Side note to the side note: ugh, is the BTS setting Reply-To
to strip out other correspondents? I have subscribed to this bug
on the BTS so I will hopefully receive all mail to it in my inbox.