Re: PL/Java new build plugin

On 07/05/20 14:35, Kartik Ohri wrote:
> Only '\r' and '\n' are not allowed in the path. Everything else should
> work.

Um, "not allowed" by what? Seems more like you are describing a case that
is possible, but not handled by your code.

As the example showed, real paths on the system are allowed to contain
those characters.

The limitation here is that the pg_config output will be incorrectly parsed
if they do, leading probably to a mysterious PL/Java build failure, quite
similar our existing issue #261, which was caused by other code assuming
a directory name would never contain whitespace.

Solving issue #261 will be one of the benefits of your work this summer,
by ending our reliance on that other faulty code.

... which is a good reason to think hard about whether the new code should
be bringing in an analogous new limitation.

/In cases where there is no simple alternative/, it's acceptable to address
such limits in documentation. The release notes can say something like:

We fixed a problem where PL/Java wouldn't build in a directory whose
name contains a space, because that turned out to be not so unusual
really. At the same time, we have made things break if PostgreSQL
is in a directory with newlines, because we think that's /really/
unusual and you deserve to have our build break if you do it.

You especially deserve whatever happens if you name a directory
something like:

Hi!
BINDIR=I am a sneaky
directory.

because we are sure that would never happen except in adversarial
usage, and we don't regard building PL/Java as any kind of
privileged operation that would be of interest to an adversary,
so we are not using a threat model where that would matter.

That can be a reasonable way of explaining implementation decisions that
get made when there is no alternative that avoids the limitation, or
when the only alternatives would be too much work. You can definitely
browse through PL/Java's git history and find comments very much like that,
explaining decisions that got made when there wasn't an easy better
alternative available.

But it is a lot of explaining to have to do in a situation where
there is an alternative that doesn't have the problem, and not only
is it easy, it is the way the code did work before you changed it.

Does that make sense?

---

I hope this doesn't sound unkind; it seems like you had a belief
"the OS doesn't allow line separators in pathnames" that turned out
not to be correct. Happens all the time. When something like that happens
to me, I go through about five stages of processing it:

1. Hmm, I believed X was true and it isn't. Bummer.

2. Can I remember roughly how long I have believed X was true?

3. Have I written anything else in that time where I might have used
the belief that X was true? Any of it worth going back to review
or add test cases?

4. Can I remember from what source I first got the idea X was true?

5. Can I remember any other things Y, Z, ... that I learned from
the same source? Would this be a good time to check Y, Z, ... also?

---

The case of line separators in pathnames makes a prime example of something
that is no problem as far as the core OS is concerned, but is very widely
cautioned against /because/ it may often trigger failures in, ahem, userland
code that makes too many assumptions.

And that is a very good reason for people who are using a system, and
choosing how to name things, to be cautious in that way.

At the same time, it is not a good reason for people who write code
to write the kind of code that makes such caution necessary.

This reduces to Jon Postel's robustness principle from RFC 760, "be
conservative in what you do, be liberal in what you accept from others."

Regards,
-Chap