Re: Potentially insecure Perl scripts
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.
Reply to: