Use waffle-jna 3.2.0

[chrullrich]

I'm submitting a ...

• bug report
• feature request

Describe the issue
As previously discussed in #2668, there is a compatibility problem when using pgjdbc in JetBrains DataGrip with SSPI authentication (i.e. from a Windows client to a database server offering either SSPI or GSS-API authentication).

(For DataGrip, read "every one of the dozen or so members of JetBrains' IDE family"; they are all IDEA with slightly different default features.)

The immediate problem was fixed on 30 November when JetBrains changed the configuration of their IDE to no longer force the incompatible JNA 5.12.0 into pgjdbc's class path. On 1 December they then released the latest version of DataGrip, 2022.3, which is far more thoroughly incompatible because it uses JNA internally and cannot load the older version of JNA that waffle-jna 1.9.1 brings in.

I would like to request that pgjdbc move its waffle-jna dependency from version 1.9.1 to 3.2.0. This version uses JNA 5.12.1, the same version that DataGrip includes. This resolves the new compatibility issue.

I am aware that pgjdbc is not responsible for catering to choices made by a third party, however, if would really make my day :-).

The changes required to get a successful connection appear to be minimal (see https://github.com/chrullrich/pgjdbc/tree/waffle-jna-3.2.0). The only code change I had to make was using JNA's SspiUtil.ManagedSecBufferDesc class (added in JNA 5.0.0) instead of Sspi.SecBufferDesc. However, I cannot make any promises about the reliability of the result; all I know is that the connection works and I can load data into the IDE from my particular database. I will of course be happy to assist with any testing necessary if you can tell me what to do.

Driver Version?
42.5.2

Java Version?
11

PostgreSQL Version?
15.1

[davecramer]

can someone from Datagrip chime in here ?

[tjlee]

DataGrip uses the following dependencies for PostgreSQL JDBC 42.5

    <version version="42.5.0">
      <item type="maven" url="org.postgresql:postgresql:42.5.0"/>
      <item os="win" type="maven" url="net.java.dev.jna:jna-platform:4.5.1"/>
      <item os="win" type="maven" url="net.java.dev.jna:jna:4.5.1"/>
      <item os="win" type="maven" url="com.github.waffle:waffle-jna:1.9.1"/>
      <item type="license" name="postgresql-driver-license.txt"
            url="https://cache-redirector.jetbrains.com/download.jetbrains.com/idea/jdbc-drivers/postgresql-driver-license.txt" md5=""/>
    </version>

So, there are two ways:

1. Unwire dependencies and let users to choose a proper library themself
2. Find out the proper version for each dependency and ship them with the driver

[vlsi]

@tjlee , It looks like the key difference is that newer jna-platform require com.sun.jna.platform.win32.SspiUtil.ManagedSecBufferDesc instead of com.sun.jna.platform.win32.Sspi.SecBufferDesc

master...chrullrich:pgjdbc:waffle-jna-3.2.0#diff-242946ea29390b4d6c634db1a53f15584d56dcc229b862cb921b92f9cdf9b863L204

WDYT if we add a reflection-based check for SecBufferDesc vs SspiUtil.ManagedSecBufferDesc?

[chrullrich]

First off, I'm sorry this comment is so long (and long-winded) again.

I have recently been advised that

it's an absolute mess up in PostgreSQL JDBC and dependencies mentioned on maven

I respectfully disagree. pgjdbc just does not use the latest version of waffle-jna and therefore JNA.

The most important issue right now is that the JetBrains side does not seem to fully understand the nature of the problem; at least I have not seen anything from there that would indicate otherwise. I have gone to great lengths to explain it and even provided instructions to reproduce the problem, but it looks like we keep talking past each other.

In short, again, pgjdbc currently only works with JNA 4, but DataGrip 2022.3 forces it to use JNA 5(.12.0) because it also uses JNA 5(.12.1) internally. This issue first appeared in DataGrip 2022.3 after previous versions did not do this (or did not do it in the same way). That is, the current version of DataGrip intentionally behaves in a way that prevents SSPI auth in current pgjdbc from working.

Note that I do not mean to claim that it is DataGrip's/JetBrains' intention to break pgjdbc, but that a behavior of DataGrip that was put in there for some specific purpose interferes with pgjdbc's proper operation.

The best fix that I am currently aware of is the one I opened this bug over: Modify pgjdbc to be compatible with JNA 5 and depend on waffle-jna 3.2.0. I am concerned, however, that in doing this pgjdbc would pursue a global solution (affecting all users everywhere) to a local problem (incompatibility with a single vendor's IDEs). A superior solution would be to resolve the incompatibility on the IDE side and allow, as proposed above, "users to choose a proper library themselves" (or rather, let them choose to rely on the – already correctly declared – dependencies). The only ones who can state with certainty whether this is possible, i.e. if DataGrip can be configured or modified to allow two JNA versions (its own and pgjdbc's) to coexist, are JetBrains' developers.

A mitigating factor to the global-solution-to-local-problem is that it may well be a good idea for pgjdbc to track the current version of JNA anyway, and perhaps even provide two distributions, one each for use with JNA 4 and JNA 5, as long as the necessary code change is as minimal as it appears to be.

[davecramer]

A mitigating factor to the global-solution-to-local-problem is that it may well be a good idea for pgjdbc to track the current version of JNA anyway, and perhaps even provide two distributions, one each for use with JNA 4 and JNA 5, as long as the necessary code change is as minimal as it appears to be

We may be able to do this with reflection and not have to provide 2 versions. Something which adds quite a bit of work on our end as we have a number of versions currently.

[chrullrich]

That would mean removing the (optional) dependency on waffle-jna entirely, wouldn't it? Or is it possible to declare it without a version because by itself it has no effect anyway? I'm concerned about losing the "documentation" aspect of having it in the POM.

Agreed on the reflection, of course.

[davecramer]

Yes, I guess it would.
Not sure how to handle this since there would be no dependency and people expecting it to be there wouldn't know that they had to add it as a dependency.
I guess we could create a with and without the dependency ?

[chrullrich]

I'm no Maven expert, but from the description of optional dependencies on the Maven site

If a user wants to use functionality related to an optional dependency, they have to redeclare that optional dependency in their own project.

it seems to me that optional dependencies really have no effect on anything, they are purely informational. If that is true, pgjdbc could, instead of removing the one it has, include optional dependencies on both waffle-jna versions.

[bokken]

Unless the different versions are at different coordinates (groupId or artifactId different), only 1 version can be declared in the pom. If we want to effectively support multiple major versions, we should declare dependency on lower major version (in pom) and document/comment support for higher version being present at runtime.

…

On Sun, Dec 11, 2022 at 11:39 AM Christian Ullrich ***@***.***> wrote: I'm no Maven expert, but from the description of optional dependencies on the Maven site If a user wants to use functionality related to an optional dependency, they have to redeclare that optional dependency in their own project. it seems to me that optional dependencies really have no effect on anything, they are purely informational. If that is true, pgjdbc could, instead of removing the one it has, include optional dependencies on *both* waffle-jna versions. — Reply to this email directly, view it on GitHub <#2690 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW3U3LNQLMATGASAE43DRDWMYGUVANCNFSM6AAAAAASSLRZ4Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Chrriis]

Our application is using JNA 5 and Postgres. We now have a requirement to have Windows Authentication in place but we cannot downgrade to an earlier version of JNA, and Postgres is only compatible with old versions of JNA/Waffle.
Would it be possible to apply the patch #2720 so that JNA 5 ManagedSecBufferDesc is used by reflection, which would allow us to use recent JNA/Waffle?

[vlsi]

Thanks for the heads-up. We will release 42.7.1, and we could probably integrate the fix as well