On Mon, 19 Sep 2022 16:55:01 GMT, Sean Coffey wrote:
>> Plus one regarding "too much noise". This event is at the
>> Provider.getService() level and would reports all calls regardless the type
>> and algorithm. Crypto services which supports the delayed provider selection
>> may call Provider.
On Mon, 19 Sep 2022 16:12:18 GMT, Sean Coffey wrote:
>> Add a JFR Event for `java.security.Provider.getService(String type, String
>> algorithm)` calls.
>
> Sean Coffey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update from review com
On Mon, 19 Sep 2022 17:53:51 GMT, Lance Andersen wrote:
>>> I can remove, but I am not sure I agree we need to describe main vs
>>> attribute here given we are pointing to the Jar spec and if there is any
>>> discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess
>>> the cl
On Mon, 19 Sep 2022 19:26:53 GMT, Sean Mullan wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minor clarification for verifying an JarInputStream
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java
On Mon, 19 Sep 2022 20:04:18 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
> Please review this PR which updates the JarInputStream class description to
> clarify when the Manifest is accessible via JarInputStream::getManifest and
> JarInputStream::get[Jar]Entry.
>
> It is worth noting that with this update, we are finally documenting
> behavior that dates back to w
On Mon, 19 Sep 2022 17:25:53 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> added test
I ran the test in the reverse direction. No difference in behavi
On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> added test
As mentioned earlier in the comments...
This is a completely com
On Mon, 19 Sep 2022 18:10:17 GMT, Mark Powers wrote:
> I tested old bytes on new release. It passes. I didn't test new bytes on an
> old release because of Max's "from the future" comment. Honestly, I'm not
> sure what any of this testing proves. Maybe that the Java Object
> Serialization Spec
On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> added test
Fair enough. I'll run a test in the opposite direction.
---
On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> added test
It's still worth manually testing the opposite direction at leas
On Mon, 19 Sep 2022 17:54:57 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8291974
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> added test
I tested old bytes on new release. It passes. I didn't test new
On Mon, 19 Sep 2022 06:34:00 GMT, Alan Bateman wrote:
> > I can remove, but I am not sure I agree we need to describe main vs
> > attribute here given we are pointing to the Jar spec and if there is any
> > discussion of Pre-entry attributes, it should be in JarEntry IMHO. I guess
> > the clar
On Mon, 19 Sep 2022 17:43:35 GMT, Mark Powers wrote:
> I wrote a test to deserialize an object created and serialized before the
> fix. I compare the old object with the current object after the fix. What is
> important is not the comparison, but that deserialization doesn't throw an
> excepti
> https://bugs.openjdk.org/browse/JDK-8291974
Mark Powers has updated the pull request incrementally with one additional
commit since the last revision:
added test
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10206/files
- new: https://git.openjdk.org/jdk/pull/10206/fil
On Wed, 7 Sep 2022 19:49:53 GMT, Mark Powers wrote:
> https://bugs.openjdk.org/browse/JDK-8291974
I wrote a test to deserialize an object created and serialized before the fix.
I compare the old object with the current object after the fix. What is
important is not the comparison, but that des
On Mon, 19 Sep 2022 16:12:18 GMT, Sean Coffey wrote:
>> Add a JFR Event for `java.security.Provider.getService(String type, String
>> algorithm)` calls.
>
> Sean Coffey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update from review com
On Mon, 19 Sep 2022 17:01:40 GMT, Aleksey Shipilev wrote:
> The test helpers try to identify NSS version by parsing the relevant `.so`
> files (!) looking for "Version: ..." string. This fails at least on Ubuntu
> 22.04, where the NSS does not have any version-identifiable strings. In this
> c
> Please review this PR which updates the JarInputStream class description to
> clarify when the Manifest is accessible via JarInputStream::getManifest and
> JarInputStream::get[Jar]Entry.
>
> It is worth noting that with this update, we are finally documenting
> behavior that dates back to w
The test helpers try to identify NSS version by parsing the relevant `.so`
files (!) looking for "Version: ..." string. This fails at least on Ubuntu
22.04, where the NSS does not have any version-identifiable strings. In this
case, the test "detects" version as `0.0` and then fails. After brief
On Mon, 19 Sep 2022 16:43:26 GMT, Valerie Peng wrote:
>> Yes, I think this would generate too much noise and detract from the main
>> motivation for these events, which is to help users analyze the security of
>> algorithms that are being used by their applications at the JCE layer.
>
> Plus on
On Mon, 19 Sep 2022 15:52:08 GMT, Sean Mullan wrote:
>> I had this as the original design actually. I'm not sure how interesting it
>> would be to record such "no-service" type events. It would probably add 2-4
>> times the number of events for this event type to a typical recording, given
>>
On Mon, 19 Sep 2022 15:46:46 GMT, Sean Coffey wrote:
> This new event is disabled by default just like the other crypto related
> events that were added some time back (e.g. `TLSHandshakeEvent`). My
> assumption is that these events will be enabled for audit mode when one is
> interested in fi
> Add a JFR Event for `java.security.Provider.getService(String type, String
> algorithm)` calls.
Sean Coffey has updated the pull request incrementally with one additional
commit since the last revision:
update from review comments
-
Changes:
- all: https://git.openjdk.org/jd
On Mon, 19 Sep 2022 15:25:43 GMT, Sean Coffey wrote:
>> src/java.base/share/classes/java/security/Provider.java line 1293:
>>
>>> 1291: }
>>> 1292:
>>> 1293: if (s != null && SecurityProviderServiceEvent.isTurnedOn()) {
>>
>> Would it be useful to generate an event even for the
On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote:
> Add a JFR Event for `java.security.Provider.getService(String type, String
> algorithm)` calls.
>
This new event is disabled by default just like the other crypto related events
that were added some time back (e.g. `TLSHandshakeEvent`).
On Mon, 19 Sep 2022 15:27:05 GMT, Sean Coffey wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 32:
>>
>>> 30:
>>> 31: import jdk.jfr.Event;
>>> 32: import jdk.jfr.events.*;
>>
>> Hello Sean, rest of the changes look fine to me, except this one. Was this
>> a
On Mon, 19 Sep 2022 14:25:55 GMT, Jaikiran Pai wrote:
>> Add a JFR Event for `java.security.Provider.getService(String type, String
>> algorithm)` calls.
>
> src/java.base/share/classes/java/security/Provider.java line 1293:
>
>> 1291: }
>> 1292:
>> 1293: if (s != null && Secur
On Tue, 13 Sep 2022 14:58:11 GMT, Sean Coffey wrote:
> Ensure that security properties are only overridden if the override security
> properties file exists.
> Refactored some of the code in Security class initialization also.
> Extra test coverage for security properties file options.
This pu
On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote:
> Add a JFR Event for `java.security.Provider.getService(String type, String
> algorithm)` calls.
src/java.base/share/classes/java/security/Provider.java line 1293:
> 1291: }
> 1292:
> 1293: if (s != null && SecurityProvider
On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote:
> Add a JFR Event for `java.security.Provider.getService(String type, String
> algorithm)` calls.
I noticed that the event is disabled by default.
Is it because of concerns of too many events, or too much overhead? Or
something else?
I thi
On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote:
> Add a JFR Event for `java.security.Provider.getService(String type, String
> algorithm)` calls.
The failures reported in the GitHub Actions job look related to this change -
`jdk.jfr.event.metadata.TestDefaultConfigurations` test appears t
On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote:
> Add a JFR Event for `java.security.Provider.getService(String type, String
> algorithm)` calls.
Looks good.
-
Marked as reviewed by mullan (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9657
On Mon, 19 Sep 2022 06:45:13 GMT, Alan Bateman wrote:
> I realise you've had a few iterations with Max on this section but I'm
> concerned that the text is telling the reader that they should use the 2-arg
> constructor to verify the signatures when a JAR is signed. The default is to
> verify
On Thu, 15 Sep 2022 08:11:38 GMT, Matthias Baesken wrote:
> Currently we see on various Windows machines the following exception :
> https://bugs.openjdk.org/browse/JDK-8293097
>
> java.security.KeyStoreException: Access is denied.
>
> This should probably be enhanced a bit so that the exceptio
36 matches
Mail list logo
