Re: Potentially insecure Perl scripts
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
and they took of those years to sort-of half-document it.
I guess you mean that we should try again ? That's probably
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.
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.
Ian Jackson <firstname.lastname@example.org> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.