On Wed, 9 Nov 2022 21:14:08 GMT, Sean Coffey wrote:
>> By moving the JFR event up to the java.security.cert.CertificateFactory
>> class, we can record all generate cert events, including those from 3rd
>> party providers. I've also altered the logic so that an event is genertate
>> for every g
> By moving the JFR event up to the java.security.cert.CertificateFactory
> class, we can record all generate cert events, including those from 3rd party
> providers. I've also altered the logic so that an event is genertate for
> every generate cert call (not just ones missing from the JDK prov
On Tue, 8 Nov 2022 16:22:55 GMT, Sean Mullan wrote:
> >
>
> My vote would be to leave it out. `keytool` already emits warnings when weak
> algorithms are used. It seems we both agree that few users, will likely
> enable JFR on `keytool`. We could always add these events later, but it is
> ha
> By moving the JFR event up to the java.security.cert.CertificateFactory
> class, we can record all generate cert events, including those from 3rd party
> providers. I've also altered the logic so that an event is genertate for
> every generate cert call (not just ones missing from the JDK prov
On Fri, 4 Nov 2022 15:58:01 GMT, Sean Coffey wrote:
>> By moving the JFR event up to the java.security.cert.CertificateFactory
>> class, we can record all generate cert events, including those from 3rd
>> party providers. I've also altered the logic so that an event is genertate
>> for every g
On Fri, 4 Nov 2022 15:58:01 GMT, Sean Coffey wrote:
>> By moving the JFR event up to the java.security.cert.CertificateFactory
>> class, we can record all generate cert events, including those from 3rd
>> party providers. I've also altered the logic so that an event is genertate
>> for every g
On Thu, 3 Nov 2022 23:25:29 GMT, Sean Coffey wrote:
> > Do you think it is that useful to have keytool record events? Ok, I guess
> > some apps could be execing keytool, but that would be in a separate
> > process, and probably wouldn't have JFR enabled. Also, these certs, if used
> > for auth
> By moving the JFR event up to the java.security.cert.CertificateFactory
> class, we can record all generate cert events, including those from 3rd party
> providers. I've also altered the logic so that an event is genertate for
> every generate cert call (not just ones missing from the JDK prov
On Thu, 3 Nov 2022 17:54:35 GMT, Sean Mullan wrote:
> Do you think it is that useful to have keytool record events? Ok, I guess
> some apps could be execing keytool, but that would be in a separate process,
> and probably wouldn't have JFR enabled. Also, these certs, if used for
> authenticati
On Thu, 3 Nov 2022 17:40:53 GMT, Sean Mullan wrote:
>> Sean Coffey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - code clean up
>> - funnel cert events via generateCertificate only
>> - Revert use of x509 c
On Wed, 2 Nov 2022 15:42:08 GMT, Sean Coffey wrote:
>> By moving the JFR event up to the java.security.cert.CertificateFactory
>> class, we can record all generate cert events, including those from 3rd
>> party providers. I've also altered the logic so that an event is genertate
>> for every g
On Wed, 2 Nov 2022 15:42:08 GMT, Sean Coffey wrote:
>> By moving the JFR event up to the java.security.cert.CertificateFactory
>> class, we can record all generate cert events, including those from 3rd
>> party providers. I've also altered the logic so that an event is genertate
>> for every g
On Wed, 2 Nov 2022 15:42:08 GMT, Sean Coffey wrote:
>> By moving the JFR event up to the java.security.cert.CertificateFactory
>> class, we can record all generate cert events, including those from 3rd
>> party providers. I've also altered the logic so that an event is genertate
>> for every g
> By moving the JFR event up to the java.security.cert.CertificateFactory
> class, we can record all generate cert events, including those from 3rd party
> providers. I've also altered the logic so that an event is genertate for
> every generate cert call (not just ones missing from the JDK prov
On Thu, 27 Oct 2022 10:04:07 GMT, Sean Coffey wrote:
> Thanks for the feedback Sean. Yes - this event should also cater for the
> internal `new X509CertImpl` type calls that are sprinkled through some of the
> security libraries.
>
> Some look a bit suspicious perhaps ? I see OCSP/CertPath typ
On Tue, 25 Oct 2022 14:56:15 GMT, Sean Coffey wrote:
>> By moving the JFR event up to the java.security.cert.CertificateFactory
>> class, we can record all generate cert events, including those from 3rd
>> party providers. I've also altered the logic so that an event is genertate
>> for every
On Tue, 25 Oct 2022 14:56:15 GMT, Sean Coffey wrote:
>> By moving the JFR event up to the java.security.cert.CertificateFactory
>> class, we can record all generate cert events, including those from 3rd
>> party providers. I've also altered the logic so that an event is genertate
>> for every
On Tue, 25 Oct 2022 20:11:33 GMT, Sean Mullan wrote:
> I think this will miss cases where the certificates are part of a chain, and
> the application (or JDK code) is calling
> `CertificateFactory.generateCertPath` or `generateCertificates`, whereas the
> previous code would not have missed it
On Tue, 25 Oct 2022 14:56:15 GMT, Sean Coffey wrote:
>> By moving the JFR event up to the java.security.cert.CertificateFactory
>> class, we can record all generate cert events, including those from 3rd
>> party providers. I've also altered the logic so that an event is genertate
>> for every
On Tue, 25 Oct 2022 14:34:26 GMT, Weijun Wang wrote:
>> Code was modified to use the X509Certificate API (rather than X509CertImpl)
>>
>> it's using the X500Principal#getName() call now. Would it be better to use
>> X500Principal#toString() ?
>
> If you are only writing there and not parsing t
> By moving the JFR event up to the java.security.cert.CertificateFactory
> class, we can record all generate cert events, including those from 3rd party
> providers. I've also altered the logic so that an event is genertate for
> every generate cert call (not just ones missing from the JDK prov
On Tue, 25 Oct 2022 14:30:32 GMT, Sean Coffey wrote:
>> test/lib/jdk/test/lib/security/TestCertificate.java line 45:
>>
>>> 43: ONE("1000",
>>> 44: "CN=SSLCertificate,O=SomeCompany",
>>> 45: "CN=Intermediate CA Cert,O=SomeCompany",
>>
>> Why remove the spaces? `X500Name::toS
On Tue, 25 Oct 2022 13:51:06 GMT, Weijun Wang wrote:
>> Sean Coffey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 11 commits:
>>
>> - blessed modifiers
>> - Merge branch 'master' into 8292033-x509Event
>> - restore import sty
On Tue, 25 Oct 2022 13:44:09 GMT, Sean Coffey wrote:
>> By moving the JFR event up to the java.security.cert.CertificateFactory
>> class, we can record all generate cert events, including those from 3rd
>> party providers. I've also altered the logic so that an event is genertate
>> for every
> By moving the JFR event up to the java.security.cert.CertificateFactory
> class, we can record all generate cert events, including those from 3rd party
> providers. I've also altered the logic so that an event is genertate for
> every generate cert call (not just ones missing from the JDK prov
On Mon, 26 Sep 2022 13:45:45 GMT, Sean Coffey wrote:
> By moving the JFR event up to the java.security.cert.CertificateFactory
> class, we can record all generate cert events, including those from 3rd party
> providers. I've also altered the logic so that an event is genertate for
> every gene
By moving the JFR event up to the java.security.cert.CertificateFactory class,
we can record all generate cert events, including those from 3rd party
providers. I've also altered the logic so that an event is genertate for every
generate cert call (not just ones missing from the JDK provider imp
27 matches
Mail list logo
