.sasl/share/classes/javax/security/sasl/SaslServer.java:
57 * status = ldap.sendBindResponse(mechanism, challenge,
58 * SASL_BIND_IN_PROGRESS);
Thanks,
Max
On Mar 31, 2020, at 5:39 AM, Ivan Gerasimov wrote:
Hello!
The fix follows up on JDK-8241727 [1].
This
://bugs.openjdk.java.net/browse/JDK-8241761
WEBREV: http://cr.openjdk.java.net/~igerasim/8241761/00/webrev/
Thank in advance!
[1] https://bugs.openjdk.java.net/browse/JDK-8241727
--
With kind regards,
Ivan Gerasimov
bject)
Use either:
whose referent is equal to this referent,
or
whose referent equals this referent,
The former is easier just delete the ’s’.
Other bits look good.
Paul.
On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov wrote:
Hi Pavel!
Can this please be combined with my collec
ion count
would be at most 256.
So far we are on the same page.
With the latest webrev (webrev.01), it seems that the loop will only
be run 255 instead of 256 times as k is incremented before
comparison. Thus, I think we should fix the check.
Valerie
On 2/11/2020 12:18 PM, Ivan Gerasimov wrot
we have a way to test this? Aka: There should be a test.
Roger
On 2/10/20 8:07 PM, Ivan Gerasimov wrote:
Thank you Michael!
It's a good point about maximum length.
Here's the updated webrev with the new System property dropped and
the increased number of iterations:
http:/
quot;, so the actual iteration count is reduced by one.
Should the iteration count be 256 or 257? If the actual count should
be 257, then may be the check needs to be changed to k++ from ++k?
Valerie
On 2/10/2020 5:07 PM, Ivan Gerasimov wrote:
Thank you Michael!
It's a good point about ma
wrote:
On 2/10/2020 6:49 PM, Ivan Gerasimov wrote:
Hello!
Current implementation of the method
javax.smartcardio.CardChannel.transmit() has an internal limitation
on the maximum allowed amount of the transmitted data.
This limitation is dictated by the maximum number of iterations to
transmit
a.net/browse/JDK-8163251
WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/
If there is an agreement on the proposal, I'll file a CSR to document a
new System property.
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
Thank you Seán!
Pushed.
On 11/12/19 12:35 AM, Seán Coffey wrote:
On 11/11/2019 20:56, Ivan Gerasimov wrote:
Thank you Seán for reviewing!
On 11/11/19 7:56 AM, Seán Coffey wrote:
Nice work Ivan.
I see you've some clean up done on exception handling also. I might
have a concern on
updated webrev with this only change, comparing to the
previous one:
http://cr.openjdk.java.net/~igerasim/8233884/01/webrev/
With kind regards,
Ivan
Everything else looked fine to me.
Regards,
Sean.
On 10/11/19 09:47, Ivan Gerasimov wrote:
Hello!
There are many places in the security l
please help review this relatively lengthy (in terms of the
affected files), though mostly straight-forward cleanup?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233884
WEBREV: http://cr.openjdk.java.net/~igerasim/8233884/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
Thank you Weijun!
Pushed.
On 10/16/19 6:42 PM, Weijun Wang wrote:
The change looks fine to me.
Thanks,
Max
On Oct 17, 2019, at 9:33 AM, Ivan Gerasimov wrote:
Hello!
This is a javadoc-only cleanup.
In a few places a dash was used between the exception name and the description
under the
/PermissionCollection.html#add(java.security.Permission)
Would you please help review a trivial cleanup?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8231859
WEBREV: http://cr.openjdk.java.net/~igerasim/8231859/00/webrev/
--
With kind regards,
Ivan Gerasimov
Hi Chris!
On 10/3/19 8:05 AM, Chris Hegarty wrote:
Ivan,
On 3 Oct 2019, at 04:41, Ivan Gerasimov wrote:
...
So, I filed CSR: https://bugs.openjdk.java.net/browse/JDK-8231805 to cover the
addition of @throws paragraph in the javadoc of SocketPermission.
I would really appreciate it, if
On 10/2/19 11:40 PM, Peter Levart wrote:
Hi Ivan,
On 10/1/19 10:26 PM, Ivan Gerasimov wrote:
Hello!
The constructors of SocketPermission and FilePermission expect a
String argument with comma-separated list of actions.
If the list is malformed, then the constructors throw
IllegalArgumentExce
It's not like if we used to allow commas in arbitrary places and stopped
doing that. Instead, it just turned out that the code fails to catch
one specific pattern of malformed action list.
With kind regards,
Ivan
Cheers,
-Joe
On 10/2/2019 4:26 PM, Ivan Gerasimov wrote:
Hi Chris!
Than
penjdk.java.net/~igerasim/8230407/01/webrev/
With kind regards,
Ivan
On 10/2/19 6:44 AM, Chris Hegarty wrote:
Ivan,
On 01/10/2019 21:26, Ivan Gerasimov wrote:
Hello!
The constructors of SocketPermission and FilePermission expect a
String argument with comma-separated list of actions.
with a leading comma.
Would you please help review a simple fix, which will make the behavior
more consistent?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230407
WEBREV: http://cr.openjdk.java.net/~igerasim/8230407/00/webrev/
--
With kind regards,
Ivan Gerasimov
Thank you Sean for reviewing!
With kind regards,
Ivan
On 9/27/19 7:20 AM, Sean Mullan wrote:
Hi Ivan,
The fix looks good. Good catch.
--Sean
On 8/30/19 7:32 PM, Ivan Gerasimov wrote:
Hello!
In the two implementations of
PermissionCollection.implies(Permission), all the permissions are
m) will be executed.
The fix does not change the behavior, but helps avoid unnecessary calls
to impliesIgnoreMask().
Would you please help review a trivial fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230415
WEBREV: http://cr.openjdk.java.net/~igerasim/8230415/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
https://bugs.openjdk.java.net/browse/JDK-8211360
WEBREV: http://cr.openjdk.java.net/~igerasim/8211360/00/webrev/
Mach5 control build/testing went fine on all platforms.
Would you please help review?
--
With kind regards,
Ivan Gerasimov
Thank you Sean for review!
On 6/25/19 10:55 AM, Sean Mullan wrote:
Hi Ivan,
This fix looks good.
--Sean
On 6/20/19 10:22 PM, Ivan Gerasimov wrote:
Hello!
In PBES1Core.deriveCipherKey() there are loops that look like following:
for (int i = 0; i < iCount
ttp://cr.openjdk.java.net/~igerasim/8226543/00/webrev/
No new regression test, as the behavior was not changed.
Mach5 control job is green (tiers 1-4 on all supported platforms).
--
With kind regards,
Ivan Gerasimov
://cr.openjdk.java.net/~mullan/webrevs/8226307/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8226307
Thanks,
Sean
--
With kind regards,
Ivan Gerasimov
oreg-other
with a comment.
Thanks,
Max
--
With kind regards,
Ivan Gerasimov
Thank you Weijun!
On 4/2/19 5:46 PM, Weijun Wang wrote:
Hi Ivan,
Code change looks fine to me. The system property is also new to me and it saved a lot of
"../../..".
Thanks,
Max
On Apr 3, 2019, at 5:52 AM, Ivan Gerasimov wrote:
Hello!
I'm seeking to backport the fix
.
WEBREV: http://cr.openjdk.java.net/~igerasim/8221801/00/webrev/
Would you please help review?
--
With kind regards,
Ivan Gerasimov
Hello!
Would you please help review a trivial fix to avoid a possible
arithmetic overflow in comparison?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8217344
WEBREV: http://cr.openjdk.java.net/~igerasim/8217344/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
ks
Max
[1] https://bugs.openjdk.java.net/browse/JDK-8200468
--
With kind regards,
Ivan Gerasimov
+Cleaner.create().register(this,
+() -> releaseContext(ctxt));
Thanks
Max
--
With kind regards,
Ivan Gerasimov
?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8201355
WEBREV: http://cr.openjdk.java.net/~igerasim/8201355/00/webrev/
--
With kind regards,
Ivan Gerasimov
://cr.openjdk.java.net/~igerasim/8200381/01/webrev/
With kind regards,
Ivan
On 10/1/18 4:58 PM, Bradford Wetmore wrote:
I checked the last 6 only (SSLEngine+). Looks good.
Brad
On 10/1/2018 4:37 PM, Ivan Gerasimov wrote:
Hello!
A handful of a few similar typos across core-libs/security-libs
Hello!
A handful of a few similar typos across core-libs/security-libs areas.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381
WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/
Would you please help review the fix?
--
With kind regards,
Ivan Gerasimov
ly in
java.desktop. I think I'll create another separate issue and will
assign it to someone from the jdk client team.
Thanks
Max
On Sep 15, 2018, at 2:03 PM, Ivan Gerasimov wrote:
Hello!
This is a followup of the fix of JDK-8210785 (Trivial typo fix in
X509ExtendedKeyManager javadoc).
/8210786/00/webrev/
--
With kind regards,
Ivan Gerasimov
Thank you Valerie!
With kind regards,
Ivan
On 8/23/18 5:18 PM, Valerie Peng wrote:
Changes look good.
Thanks,
Valerie
On 8/23/2018 1:40 PM, Ivan Gerasimov wrote:
Hello!
This is a smartcardio related issue.
If CardChannel.transmit() needs to issue an additional command, it
reuses the
you please help review?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-6474858
WEBREV: http://cr.openjdk.java.net/~igerasim/6474858/00/webrev/
--
With kind regards,
Ivan Gerasimov
help review the trivial fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8209851
WEBREV: http://cr.openjdk.java.net/~igerasim/8209851/00/webrev/
--
With kind regards,
Ivan Gerasimov
r good catch!
updated webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8209129.v3/webrev/
regards,
Sean.
Otherwise fine.
Thanks
Max
On Aug 17, 2018, at 12:53 AM, Seán Coffey
wrote:
Find new webrev here Max :
http://cr.openjdk.java.net/~coffeys/webrev.8209129.v2/webrev/
regards :
--
With kind regards,
Ivan Gerasimov
urity/krb5/auto/SpnegoUnknownMech.java
--
With kind regards,
Ivan Gerasimov
Hello!
Would you please help review the fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186186
WEBREV: http://cr.openjdk.java.net/~igerasim/8186186/01/webrev/
With kind regards,
Ivan
/8207031/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
Thanks Seán!
On 5/31/18 12:13 PM, Seán Coffey wrote:
Looks fine Ivan.
Approved for jdk8u-dev.
regards,
Sean.
k-cpu/open/rev/2d250a0174a6
Jdk 11 review:
http://mail.openjdk.java.net/pipermail/security-dev/2018-January/016675.html
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
/8186628_ssl_session_cache_scalability/webrev.01/
--
With kind regards,
Ivan Gerasimov
/8193171/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
nezih yigitbasi wrote:
Ivan, thanks for the information. Any ideas about when one of these
solutions can be released?
Nezih
2018-04-20 9:22 GMT-07:00 Ivan Gerasimov <mailto:[email protected]>>:
Hello Nezih!
This issue is still being discussed off-list.
There have bee
regarding
that issue.
Thanks,
Nezih
--
With kind regards,
Ivan Gerasimov
Ping.
Can I please have a review for this test fix?
Thanks in advance!
Ivan
On 3/6/18 1:01 PM, Ivan Gerasimov wrote:
Hello!
The regression test SignatureLength.java was seen to fail on some
Solaris systems.
This is because signature verifier from SunPKCS11-Solaris provider
doesn&#
It looks good!
With kind regards,
Ivan
On 3/6/18 6:19 PM, Weijun Wang wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8199198/webrev.00
I just removed the 3 unused functions. They were there from the beginning
(2005) but had never existed in any Java class.
Thanks
Ma
EBREV: http://cr.openjdk.java.net/~igerasim/8178370/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
ebrev/
JDK 10 Change: http://hg.openjdk.java.net/jdk/jdk/rev/e3b6cb90d7ce
JDK 10 Review:
http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016613.html
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
Thank you Sean for review!
On 12/13/17 11:00 AM, Sean Mullan wrote:
Looks fine to me.
--Sean
On 12/13/17 1:02 PM, Ivan Gerasimov wrote:
Ping!
The patch is the anti-delta of the fixes, so we're just reverting to
what we used to have prior these fixes.
Would you please help review
Ping!
The patch is the anti-delta of the fixes, so we're just reverting to
what we used to have prior these fixes.
Would you please help review this and approve the backport?
With kind regards,
Ivan
On 12/11/17 9:30 AM, Ivan Gerasimov wrote:
Hello!
I'm seeking an approval t
56/01/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
hanks,
Sean
On 12/6/17 8:35 PM, Ivan Gerasimov wrote:
Hello!
A regression caused by the recent fixes of the ProtectionDomain cache
was observed.
Thus, it is proposed to revert the corresponding changes for now.
Would you please approve this patch, which is actually an anti-delta
of three ment
/browse/JDK-8193156
WEBREV: http://cr.openjdk.java.net/~igerasim/8193156/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
Thank you Max!
Yes, I've just added noreg-trivial.
With kind regards,
Ivan
On 12/2/17 11:26 PM, Weijun Wang wrote:
Hi Ivan
The change looks fine.
Do you want to add a noreg-trivial or noreg-hard label?
Thanks
Max
On Dec 3, 2017, at 3:03 PM, Ivan Gerasimov wrote:
Hello!
It was no
jdk.java.net/browse/JDK-8187985
WEBREV: http://cr.openjdk.java.net/~igerasim/8187985/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
Hello!
There is a redundant variable assignment, which seems to be copy-paste
of the line 1404.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8187497
WEBREV: http://cr.openjdk.java.net/~igerasim/8187497/00/webrev/
Would you please help review this trivial fix?
--
With kind regards,
Ivan
Thank you for review! Pushed.
With kind regards,
Ivan
On 11/21/17 10:32 PM, Weijun Wang wrote:
This looks fine to me.
Thanks
Max
On Nov 22, 2017, at 9:47 AM, Ivan Gerasimov wrote:
Hello!
Here's a simple fix to correctly handle the malloc call returning NULL.
BUGURL:
ize).
With kind regards,
Ivan
Regards, Peter
On 11/21/17 14:16, Ivan Gerasimov wrote:
Thanks Xuelei for the comment!
On 11/20/17 8:50 PM, Xuelei Fan wrote:
Hi Ivan,
I understand the desire of performance improvement. But I don't
think avoiding the use of cache is the price we want
Hello!
Here's a simple fix to correctly handle the malloc call returning NULL.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068024
WEBREV: http://cr.openjdk.java.net/~igerasim/8068024/00/webrev/
Would you please help review?
--
With kind regards,
Ivan Gerasimov
help to
improve performance.
With kind regards,
Ivan
Xuelei
On 11/20/2017 5:36 PM, Ivan Gerasimov wrote:
Gentle ping.
If people agree on the approach, I'll go ahead and file a CCC request
for the new recognized system property.
With kind regards,
Ivan
On 11/7/17 6:24 PM, Ivan
Gentle ping.
If people agree on the approach, I'll go ahead and file a CCC request
for the new recognized system property.
With kind regards,
Ivan
On 11/7/17 6:24 PM, Ivan Gerasimov wrote:
Hello everybody!
The class sun.security.ssl.SSLSessionContextImpl maintains caches for
e, it would be able to take
advantage of re-using the contexts.
Though I'm not sure how to size or re-size the index based on load or ...
I would think that using a 'small' cache size would bound the expunge
time and still allow some-reuse.
$.02, Roger
On 11/8/2017 2:09 PM,
ttp://bernd.eckenfels.net
*From:* security-dev on behalf
of Ivan Gerasimov
*Sent:* Wednesday, November 8, 2017 3:24:54 AM
*To:* [email protected]
*Subject:* [10] RFR : 8186628 : SSL session cache can cause a
scalability bottleneck
He
,
Ivan Gerasimov
On 9/7/17 10:25 AM, Seán Coffey wrote:
Looks good to me Ivan.
Thanks Seán!
With kind regards,
Ivan
regards,
Sean.
On 23/08/2017 21:54, Ivan Gerasimov wrote:
Hello!
An auxiliary class EqualByteArray implements hashCode() in a way that
small changes to the content do not change the hash
On 8/31/17 1:44 PM, Anthony Scarpino wrote:
On 08/31/2017 01:10 PM, Ivan Gerasimov wrote:
Hello!
Currently, when reading the pkcs11 config file, the default encoding
is assumed.
This causes errors when the encoding is set to UTF-16.
Would you please help review the trivial fix?
Bug
/8187023/00/webrev/
--
With kind regards,
Ivan Gerasimov
-8186654
WEBREV: http://cr.openjdk.java.net/~igerasim/8186654/00/webrev/
--
With kind regards,
Ivan Gerasimov
k/rev/87290d66b649
Jdk10 review:
http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015790.html
Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8140436/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
Hello!
It was reported that there's broken behavior exposed when the debug mode
is turned on, which is due to KerberosTicket.toString() throwing an
exception, if the ticket was already destroyed.
The proposed fix is in fact the backport of a tiny portion of JDK-8043071.
BUGURL: https://bugs.
Hello!
Could someone with the Reviewer's rights please help review and approve
this fix?
The latest webrev can be found here:
http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/
Thanks in advance,
Ivan
Thank you Sean!
However, my initial evaluation occurred to be wrong: the failure was due
to a different reason, so I reassigned the bug.
With kind regards,
Ivan
On 21.10.2016 14:34, Sean Mullan wrote:
Looks good. Add noreg-self label to the bug.
--Sean
On 10/21/2016 05:37 AM, Ivan
Hello!
A compilation issue with the regression test was observed due to
ambiguity between two X509ExtendedTrustManager classes.
The fix is to organize the imports.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8168468
WEBREV: http://cr.openjdk.java.net/~igerasim/8168468/00/webrev/
Would y
Hello!
Would you please help review and give the approval to backport this fix?
The changes in the backport, comparing to the fix in 9, are due to
different file structure and the different previous value of the property.
Bug: https://bugs.openjdk.java.net/browse/JDK-8167591
Jdk9 change: http
From: security-dev [mailto:[email protected]] On Behalf
Of Ivan Gerasimov
Sent: Dienstag, 6. September 2016 22:07
To: Artem Smotrakov ; security-
[email protected]
Subject: Re: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
should use operator new (nothrow) fo
not found
1415 }
...
Thanks!
Artem
On 09/06/2016 01:07 PM, Ivan Gerasimov wrote:
Hi Artem!
On 06.09.2016 20:45, Artem Smotrakov wrote:
Hi Ivan,
It's not really about your changes, but I am wondering if "delete []
pszNameString" should be called before "conti
ake the deallocation logic
more clear.
There seems to be another, more promising memleak in
loadKeysOrCertificateChains(), which I'm investigating at the moment.
I think these two leaks can be fixed together.
With kind regards,
Ivan
Artem
On 09/06/2016 02:54 AM, Ivan Gerasimov wrote:
t] On Behalf
Of Ivan Gerasimov
Sent: Montag, 5. September 2016 21:53
To: [email protected]
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi should
use operator new (nothrow) for allocations
Hello!
In the native layer of sunmscapi provider, for memory allocations the
Hello!
In the native layer of sunmscapi provider, for memory allocations the
::operator new() is used.
In (a very unlikely) case of failure, it will raise a C++ exception of
type bad_alloc, which is bad, as we don't have handling code.
One simple way to improve the situation would be to use :
make this mistake
anymore?
Good point. Let's remove it!
With kind regards,
Ivan
Thanks
Max
On 9/4/2016 3:30, Ivan Gerasimov wrote:
Hello!
Just a few minor typos found across the security-lib javadoc.
Please help review.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165413
WE
Hello!
Just a few minor typos found across the security-lib javadoc.
Please help review.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165413
WEBREV: http://cr.openjdk.java.net/~igerasim/8165413/00/webrev/
With kind regards,
Ivan
Hello!
When underlying PCSC driver returns the error SCARD_E_NO_SMARTCARD, we
should throw a more specialized exception of type CardNotPresentException.
Currently, the plain CardException is thrown, which makes some TCK tests
unhappy.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-6474807
necessary, so if the context could be acquired silently (i.e. the
result is TRUE), it will be possible to acquire it with no UI and
without explicit SILENT flag.
With kind regards,
Ivan
Changes look fine.
Valerie
On 8/16/2016 1:06 PM, Ivan Gerasimov wrote:
Thank you Valerie for looking into
variant, the slowdown isn't
noticeable by eye, but it surely will be worthwhile to do some benchmarking.
With kind regards,
Ivan
Thanks.
On 16 Aug 2016, at 13:56, Ivan Gerasimov wrote:
A gentle reminder.
Would you please help review at your convenience.
With kind regards,
Ivan
On 09.08
,
Ivan
Anything that I missed?
Valerie
On 8/16/2016 6:27 AM, Vincent Ryan wrote:
That fix looks fine. Is there any significant performance impact due to calling
CryptAcquireCertificatePrivateKey twice?
Thanks.
On 16 Aug 2016, at 13:56, Ivan Gerasimov wrote:
A gentle reminder.
Would you p
A gentle reminder.
Would you please help review at your convenience.
With kind regards,
Ivan
On 09.08.2016 12:27, Ivan Gerasimov wrote:
Hello!
In order to reduce the number of popup dialog windows during accessing
the smartcard, it is proposed to first do a silent "probe" ste
Thank you Vincent for review!
With kind regards,
Ivan
On 15.08.2016 19:13, Vincent Ryan wrote:
Thanks Ivan. Your fix looks good.
On 13 Aug 2016, at 02:15, Ivan Gerasimov wrote:
Hello!
It was noticed, that SunMSCAPI implementation of a KeyPair has a problem: The
public and the private
ase. Could you make it
more generic ? i.e. don't just test the MSCAPI provider. Let's cycle
through all providers available for KeyPairGenerator and ensure no
other provider suffers (or introduces) the same issue.
Regards,
Sean.
On 13/08/16 02:15, Ivan Gerasimov wrote:
Hello!
Hello!
It was noticed, that SunMSCAPI implementation of a KeyPair has a
problem: The public and the private keys share the same native handles.
As the result, when one of the keys is finalized, and its resources are
freed, the second key becomes invalid.
Would you please help review the fix
Hello!
In order to reduce the number of popup dialog windows during accessing
the smartcard, it is proposed to first do a silent "probe" step.
Only if this probe succeeded, or if it failed due to that SILENT flag,
we'll try to re-acquire the key normally (i.e. not silently).
Would you please
Hello!
I'd like to backport this fix into jdk8u-dev.
The fix is essentially the same as in jdk9, but could not be used
verbatim because of the code derivation.
Bug: https://bugs.openjdk.java.net/browse/JDK-8160518
Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d5c6e8bad2d
Jdk9 revie
ards,
Ivan
Thanks
Max
On Jul 5, 2016, at 1:03 AM, Ivan Gerasimov wrote:
Hello!
We've got a complain that a semicolon character cannot be used to start a
comment in the kerberos config file.
In the documentation [1] I don't see mentioning comments at all, but it is said
that the config
Hello!
We've got a complain that a semicolon character cannot be used to start
a comment in the kerberos config file.
In the documentation [1] I don't see mentioning comments at all, but it
is said that the config file is in style of Windows INI file, and the
later does allow semicolons to be
Hello!
When backporting JDK-8158633 to jdk8u, it was noticed that OracleUcrypto
provider may experience difficulties reading its config file in UTF-16
environment.
The fix is to explicitly specify the expected encoding of the config file.
Would you please help review the fix?
BUGURL: https:
Thank you Seán and Xuelei for your reviews!
With kind regards,
Ivan
On 03.07.2016 15:43, Xuelei Fan wrote:
On 7/3/2016 8:37 PM, Seán Coffey wrote:
Looks like a good test fix to me Ivan.
+1.
Xuelei
Regards,
Sean.
On 29/06/2016 16:20, Ivan Gerasimov wrote:
Hello!
The mentioned test was
Looks good!
Similar typo is found in another file:
java.security.jgss/share/classes/sun/security/jgss/spi/GSSContextSpi.java:
* Return the mechanism-specific attribute associated with (@code type}.
May be worth fixing it together.
With kind regards,
Ivan
On 30.06.2016 10:39, Jamil Nimeh wro
1 - 100 of 165 matches
Mail list logo
