[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] printing from the mac sandbox
From:       Sean Reilly <sreilly () infinitekind ! com>
Date:       2017-07-03 22:30:28
Message-ID: FFB6BC7E-C3A3-4638-9475-DF8600EEE530 () infinitekind ! com
[Download RAW message or body]

> On 2017.06.02, at 18:06, Phil Race <philip.race@oracle.com> wrote:
> > 2) Is there a reason not to use the unix domain socket connection? The connection \
> > details seem to be encapsulated within the libcups code so I don't see why the \
> > java level needs to override the result returned by the call to `cupsServer`
> 
> I don't follow your comment about encapsulation in libcups code.
> The server name is returned to Java code and there a connection is made over HTTP.
> The socket string would not work there .. and Java does not have any support I know \
> of for Unix domain sockets anyway. This would seem to require a lot of re-working \
> of the code unless I am missing something.

I'm not sure how much reworking it would require, but IMO a bug preventing printing \
in any sandboxed (ie mac app store) app is a big deal.

> Also I asked someone with 10.12.5 to run the following program and it worked fine \
> for them. What is your program doing and how are you running it ?

The test code you included wouldn't reveal the problem because it wasn't running \
within the mac sandbox.

I've created a small test case that shows the problem:
 https://infinitekind.com/tmp/javacups/

 SandboxedJavaTestPrint.zip - has a signed sandboxed java app as well as the source \
and scripts that were used to build it.  I've signed it with my developer key and \
added a debugging flag \
(-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005) so that you can \
trace through the steps while it runs within the sandbox.

 TEST CUPS Sandboxed.zip - contains an objective-c/Xcode project which shows how \
native connections to localhost port 631 through the CUPS API time out, but how \
passing the result of a call to cupsServer() (which returns the unix domain socket \
path) to httpConnect2() results in a successful connection.  This shows that we can \
still (probably) use a call to httpConnect/httpConnect2, but the java-side code that \
assumes cupsServer() returns a hostname will need to change.  It's not a trivial \
change, but it also doesn't look like it gets too hairy... mainly some changes in \
UnixPrintServiceLocalLookup.java and IPPPrintService.java.

Both test apps have network-client and printing entitlements in the sandbox.

The problem mainly seems to be a delay (often measured in tens of minutes) when \
attempting to print.  Curiously the print dialog does appear after a very long delay \
and printing can then proceed.  This makes me think that the problem is related to \
discovery of printers or print services for which there is a fallback.

I've submitted a DTS incident to Apple and a friend there has followed-up. Their \
unofficial position is that java should be connecting to the cups interface returned \
by the cupsServer() function and not changing the interface string to "localhost".  \
Security changes in 10.12.4 reject the TCP connection which they say confuses \
network-client access with print access.  They don't seem interested in loosening \
that change.

You can find Apple's CUPS port in github:  https://github.com/apple/cups
Their github repo seems to be a bit ahead of what is shipped in macOS Sierra.

I'm still digging into this, but would appreciate hearing if Oracle would be \
interested in helping resolve the issue.

Thanks,
Sean


["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZWsWEAAoJED7VrAhh0wRfKFgQAIMVvSjuWzAqwaF0+Ftq+pst
KmlGs3IQ95786D8Jhcsxn+aM6lDl3VhfUnfiJPu8WAAhQP1aX1N3hpw9YfF3Q1NO
1PE9C5VOOfljBjHH0gtfHEio4zTRLPXkXl9FqxN+9Bmr1E3PBsWvCpAbKPFnVIXM
85mRx8UTfjJiMj6ycEnTQJUED54oDXjsaFrQgdbJNRirPkclkcw+/u02qakiF4ra
EZBTJPbxUvEzYqBLYCJ+dMTFZe6Dxm8Fs+t4dEQkbSSmaDvBW5gfwtUY8ZI18+S9
Zskvv1zrCdQELHOlOE37RPgwh7Bfy/0OnrKYbemMDiIjL2JQ6oE9cy69uCIFXly5
spX0Rk0uNvlS16yH9PlFnl4F0UU1lCi3iy3ERaZYvvrazCR7HLis/BND3CLaWeey
1uM4VRzWWSb4bI1Y4z1ZKyCZAIo3bAeuziJGYhDb6t+MhthAoMaMvf3SXx3ibcd2
69vzfwwnoJyUZR4CEHfPHfowX1m1Q1FGOsb9prEtjkDLxW6ewb3wK1jz7ATLAZX2
IBqtqNXoAtpbBpDN2wfh5T7XsHxaXntVoOQ3Z2FOQqdUISPFh64DHtM7eNq8nkfQ
n7YsDsDgbhAOvDHx26ucPlO7LtLFRuxuhTxLIslTF+i4QW2GSoKp03Eh0DnGeiUi
sZLgiC6pBeEW75iitYtj
=4eoZ
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]