On Fri, Jan 25, 2019 at 07:41:52PM +0000, Ian Jackson wrote:
> Holger Levsen writes ("Re: Potentially insecure Perl scripts"):
> > On Thu, Jan 24, 2019 at 03:18:40PM +0000, Ian Jackson wrote:
> > > To the Debian Perl maintainers: [...]
> > > To the Debian security team: [...]
> >
> > I've read the whole thread and am surprised "talking to upstream" (and
> > fixing the issue there as well) hasn't really been on the table. :/ Did I
> > miss that?
>
> This bug was reported upstream here 18 years ago
> https://rt.perl.org/Public/Bug/Display.html?id=2783
> and they took of those years to sort-of half-document it.
>
> I guess you mean that we should try again ? That's probably
> worthwhile.
>
> Maybe it would be best if this were fronted by someone who can bring
> themselves to be more diplomatic about this situation than I can find
> it in myself to be right now.
Myself or Niko can deal with taking this conversation upstream, but
please allow some time for this.
> In the meantime we do need to bear in mind that we do have
> approximately these two options:
>
> 1. Change the behaviour of perl so that it matches the majority of
> the documentation, so that -n and -p and <> fulfil their purpose
> and can be used, and so that they satisfy the expections (or at
> least wishes) of the vast majority of Perl programmers.
>
> Risk a probably tiny amount of fallout.
>
> If we do this in Debian without cooperation from upstream, set an
> example which might lead other distros to fix it too; albeit
> through diverging from upstream behaviour.
>
> 2. Internally in Debian file a massive MBF to review thousands
> and thousands of uses for safety.
>
> Leave the world's existing scripts to be insecure and tolerate
> that people will continue to write insecure scripts.
>
> Write clumsy circumlocutions everywhere instead of <> and -p and
> -n. (Note that <<>> is not right because it does not honour `-'.)
>
> Add notes to the documentation saying never to use <> or
> -p or -n (WTF).
>
> (2) certainly cannot be done quickly. If (1) cannot be done quickly
> it should IMO be done slowly.
Again - please do not force us to rush this. It is not a new situation
so rushing and panicing is not warranted.
Fixing this situation in collaboration with upstream is the only sane
approach, however the final details are worked out.
Dominic.
