Hi, October 26, 2021 9:45 PM, "Philip Race" <philip.r...@oracle.com> wrote:
> Hi, > Could you sign up for the mailing list ? I keep having to manually process > these > which is work as well as delay .. I have now done that. > And the one for this seems to have gone AWOL, not sure what happened with > mailman. I'm afraid that was my mistake. I failed to hit "reply to all", and instead replied just to you. Sorry! > > Comments below. > > On 10/26/21 7:01 AM, Rolf van Kleef wrote: > >> October 22, 2021 7:05 PM, "Philip Race" <philip.r...@oracle.com> wrote: >> >>> Well .. >>> >>> 1) Please read the comment the bots added to your PR. >>> There are steps you need to take before we can even look at your >>> contribution. >>> >>> 2) PRs need a JBS bug ID else the bots will still reject it. >>> You'll need to submit an RFE at bugreport.java.com and go from there. >> >> I have submitted a bug, and added a bug ID to the PR. The only remaining >> requirement appears to e >> acquiring a review. > > Mostly .. although this actually needs an approved CSR too since it > introduces a new "interface" I see. Would looking up the binary on $PATH still require this? >>>> 3) I understand your problem up to a point but we'd need to think about >>>> the proposed solution >>> and why your Linux doesn't put lpr in the standard place. There could be >>> legitimate >>> security concerns about allowing such an over-ride. >>> Perhaps you need a port of OpenJDK to that distro which you don't name ? >> >> This specifically concerns Flatpak, where it is entirely non-trivial to >> place files outside of the >> /app directory. I would be interested to hear about these aforementioned >> security concerns. > > I see (sort of) I only recently heard of Flatpak. > > I guess this also means it maybe isn't enough (even if it were OK, which I > doubt it is) > to expect that "lpr" be available on the path as a fallback to /usr/bin/lpr ? This would be enough for Flatpak. We have full control over the path. >> Presumably if someone is able to set system properties, there are bigger >> problems? > > Not entirely disagreeing .. but we've had to deal with issues in the past > where > the security team had concerns with things that are sufficiently similar I'd > need to get their OK I see >> I am very open to discussing alternative solutions. > > Me too .. if I could think of any. > Maybe we can FIRST try /usr/bin/lpr and only look at the property if the > command doesn't exist .. > That might make the security team happier because you'd need to be able to > remove things > in /usr/bin and if someone can do that then you REALLY have problems. That makes sense. I'll suggest a new change where /usr/bin/lpr is tried first, and then the binary is looked for on the $PATH. > -phil. > >>> -phil >>> >>> On 10/22/21 5:42 AM, Rolf van Kleef wrote: >> >> I am not sure about whether this is the correct list for this, or whether >> this is an appropriate >> message for this list, but I have been told to send an email here regarding >> a PR I submitted on >> GitHub. >> >> I recently ran into trouble with printing on Linux, where the lpr binary was >> on a non-standard path >> (not in /usr/bin/lpr). After looking in the code, I found out that this path >> cannot be overridden. >> It seems that such paths should be able to be overriden, and so, I propose >> to add a system property >> named "sun.print.lprPath" and "sun.print.lpPath" to override these paths. >> See the PR below. >> >> https://github.com/openjdk/jdk/pull/6052 >> >> Regards, >> Rolf van Kleef
