On Fri, 21 Jun 2024 16:11:34 GMT, Rajan Halade wrote:
>> Updated all the tests that depend on external infrastructure services as
>> manual. These tests may fail with external reasons, for instance - change in
>> CA test portal, certificate status updates, or network issues.
>
> Rajan Halade ha
On Tue, 29 Aug 2023 21:59:37 GMT, Andrew John Hughes wrote:
>> Currently, security properties are held within the `java.security` file in
>> the JDK tree for each installed JDK. The system property
>> `java.security.properties` can be used to point to a file contain
On Thu, 9 Nov 2023 21:36:44 GMT, Weijun Wang wrote:
> My major concern is that this does not look like a properties file anymore,
> that the same key have multiple values and you use an undocumented (?) format
> "key value". That said, this is a clever hack and I wonder why we hadn't used
> it
On Fri, 3 Nov 2023 22:18:22 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>>
On Tue, 5 Sep 2023 10:17:31 GMT, Andrew John Hughes wrote:
>> There is a long standing limitation in the UNIX smartcardio implementation
>> which means it will only look for the `pcsclite` library in two locations;
>> `/usr/lib` and `/usr/local/lib`. It also only searches
On Thu, 24 Aug 2023 00:53:03 GMT, Andrew John Hughes wrote:
> There is a long standing limitation in the UNIX smartcardio implementation
> which means it will only look for the `pcsclite` library in two locations;
> `/usr/lib` and `/usr/local/lib`. It also only searches for an un
On Wed, 30 Aug 2023 06:25:44 GMT, Thomas Stuefe wrote:
>>> Changes look fine. I submitted a mach5 test job just in case. Will approve
>>> once the test job passes. BTW, I added a noreg-other label since there is
>>> no regression test for this change.
>>
>> Thanks. Yes, I don't see how we can
On Wed, 30 Aug 2023 06:25:44 GMT, Thomas Stuefe wrote:
>>> Changes look fine. I submitted a mach5 test job just in case. Will approve
>>> once the test job passes. BTW, I added a noreg-other label since there is
>>> no regression test for this change.
>>
>> Thanks. Yes, I don't see how we can
On Wed, 30 Aug 2023 06:25:44 GMT, Thomas Stuefe wrote:
> Yes, that's a bit tricky. I was concerned about the JVM picking up the wrong
> library on a mulitarch system, since having multiple of these directories is
> the point of multiarch.
>
If the architecture is not 32-bit arm and the librar
rName("sun.security.smartcardio.PlatformPCSC");
> Method m = cls.getDeclaredMethod("getLibraryName");
> m.setAccessible(true);
> System.err.println(m.invoke(null));
> }
> }
> ~~~
>
> 1. With `libpcsclite.so.1` available:
On Fri, 25 Aug 2023 00:39:14 GMT, Valerie Peng wrote:
> Changes look fine. I submitted a mach5 test job just in case. Will approve
> once the test job passes. BTW, I added a noreg-other label since there is no
> regression test for this change.
Thanks. Yes, I don't see how we can have a regres
On Fri, 25 Aug 2023 05:39:39 GMT, Thomas Stuefe wrote:
> Hi @gnu-andrew,
>
> in your last example, why does it look for both arm and x64 packages? And why
> for kFreeBsd? I see you have both hardcoded, why?
>
> I would expect it only to attempt and pick up the architecture and OS the VM
> was
On Thu, 24 Aug 2023 01:27:55 GMT, Martin Balao wrote:
> As commented here [1], @franferrax and I have been working on a different
> approach to this problem. We suggest to put this PR on hold until we have our
> proposal ready to compare and discuss further.
>
> -- [1] -
> https://bugs.openjd
ble version of this patch (a permanent hardcoded single file) has
> been [used in our JDK installations since
> 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a
> system-wide crypto policy. Having support for this in the upstream JDK would
> allow us to remove a local
There is a long standing limitation in the UNIX smartcardio implementation
which means it will only look for the `pcsclite` library in two locations;
`/usr/lib` and `/usr/local/lib`. It also only searches for an unversioned
library.
On systems that separate libraries from development headers in
On Fri, 2 Jun 2023 12:58:36 GMT, Andrew John Hughes wrote:
>> Currently, security properties are held within the `java.security` file in
>> the JDK tree for each installed JDK. The system property
>> `java.security.properties` can be used to point to a file containing
>&g
ble version of this patch (a permanent hardcoded single file) has
> been [used in our JDK installations since
> 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a
> system-wide crypto policy. Having support for this in the upstream JDK would
> allow us to remove a local
On Fri, 2 Jun 2023 11:54:00 GMT, Weijun Wang wrote:
>> Currently, security properties are held within the `java.security` file in
>> the JDK tree for each installed JDK. The system property
>> `java.security.properties` can be used to point to a file containing
>> additional properties. These
On Fri, 2 Jun 2023 02:01:00 GMT, Alexey Bakhtin wrote:
>> Currently, security properties are held within the `java.security` file in
>> the JDK tree for each installed JDK. The system property
>> `java.security.properties` can be used to point to a file containing
>> additional properties. The
Currently, security properties are held within the `java.security` file in the
JDK tree for each installed JDK. The system property `java.security.properties`
can be used to point to a file containing additional properties. These can be
appended to the existing set or override all existing prope
20 matches
Mail list logo
