- Original Message -
> On 5/20/2013 5:28 PM, Pasi Eronen wrote:
> > Hi Xuelei,
> >
> > It seems the PKSC11 doesn't actually have this bug.
> >
> > P11KeyAgreement has a separate code path for the "TlsPremasterSecret"
> > algorithm, which strips leading zeroes if the key can be extracted f
> Sean.
>
> On 22/05/2013 19:25, Andrew Hughes wrote:
> > Webrev: http://cr.openjdk.java.net/~andrew/7u/webrev/
> >
> > There's an ambiguity that applies when building OpenJDK 7 with OpenJDK 6
> > (and hence I haven't p
- Original Message -
>
> Won't this change break systems which don't have libpcsclite.so.1?
> Changes like this need to be thought through. What happens when
> libpcsclite.so.2 comes out?
> As for API changes, shouldn't there be some compatibility requirement on
> APIs as libpcsclite.so ev
- Original Message -
> On 02/04/2014 04:48 PM, Andrew Hughes wrote:
>
> > As has already been mentioned on this thread, libraries should have their
> > version increased when the ABI changes. Thus, a libpcsclite.so.2 or later
> > would indicate a different ABI t
intended the latter. Generally speaking
> codereview requests would say "Request for review" as opposed to
> "Request for approval" so a reviewer could overlook your mail if you
> intended the former.
>
> -Rob
>
> On 18/09/14 00:21, Andrew Hughes wrote
e matches the push approval
> > template I understood that you intended the latter. Generally speaking
> > codereview requests would say "Request for review" as opposed to
> > "Request for approval" so a reviewer could overlook your mail if you
> > intended t
months.
Thanks.
> regards,
> Sean.
>
> On 01/10/2014 16:11, Andrew Hughes wrote:
> > - Original Message -
> >>
> >> - Original Message -
> >>> Code changes generally require two approvals: codereview, performed by a
> >>
- Original Message -
> Considering that the issue was a P3 RFE rather than a high priority bug fix,
> it's not clear to me why it would be necessary to backport it into 7u80, at
> the end point in the release cycle.
>
I don't have anything to do with the assignment of such priorities.
>
Maher
>
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment
>
> > On 24.12.2014, at 17:09, Andrew Hughes wrote:
> >
> > - Original Message -
> >>
- Original Message -
> On 3/14/12 9:08 AM, Andrew Hughes wrote:
> > 1. java.security is altered to prioritise
> > com.oracle.security.ucrypto.UcryptoProvider
> > on Solaris builds. What does this mean for OpenJDK builds on
> > Solaris that don't hav
- Original Message -
>
> On 03/15/12 16:29, Andrew Hughes wrote:
> >>> 2. Was there a reason the testcases in this commit were locked
> >>> down
> >>> to only work with the proprietary ucrypto provider? Are they not
> >>> suitable
Hi all,
As discussed in:
http://mail.openjdk.java.net/pipermail/security-dev/2012-March/004615.html
this webrev:
http://cr.openjdk.java.net/~andrew/enc_tests/webrev.01/
updates the tests as follows:
1. Tests all available providers, not just ucrypto which is unavailable on
OpenJDK.
2. No l
d generalised them rather than Oracle hiding them away in a private
repository.
>
> Personally, I feel this is a bit more than "regression tests"...
> Valerie
>
> On 03/29/12 07:43, Andrew Hughes wrote:
> > Hi all,
> >
> > As discussed in:
> >
&
- Original Message -
> [cc'ing net-dev mailing list]
>
> Thanks for reporting this issue.
>
> This looks like 7089443 [1], fixed in jdk8 via 7112670 [2]. Looks
> like
> icetea needs to sync up, or maybe they are based against the jdk7
> repo.
The report is from OpenJDK6:
/usr/lib/jvm/ja
- Original Message -
> Please review these changes to correct a problem loading Mozilla NSS
> on multi-arch Ubuntu:
>
>http://cr.openjdk.java.net/~vinnie/7190945/webrev.00/
>
> Thanks.
>
NSS works fine here with this change applied. The libraries are still being
loaded successfully
This is an issue that has been with us for a while. See:
https://bugs.openjdk.java.net/show_bug.cgi?id=100062
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188845
for some background.
The original proposed patch goes to far in removing most of the
infrastructure for restricting crypto lev
gt; It seems fine with me.
> > But I think someone from the security team should chime in on this.
> >
> > -kto
> >
> > On Sep 18, 2012, at 7:39 AM, Andrew Hughes wrote:
> >
> >> This is an issue that has been with us for a while. See:
> >>
&
- Original Message -
> On Tue, 2012-09-18 at 10:39 -0400, Andrew Hughes wrote:
> > This is an issue that has been with us for a while. See:
> >
> > https://bugs.openjdk.java.net/show_bug.cgi?id=100062
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_i
- Original Message -
>
>
> On 9/18/2012 7:39 AM, Andrew Hughes wrote:
> > The following simple webrev will achieve what I think is needed:
> >
> > http://cr.openjdk.java.net/~andrew/100062/webrev.01/
> >
> > allowing OpenJDK to be built with the u
- Original Message -
>
> >> Will you be putting this back yourself? If so let me know when
> >> you
> >> go
> >> in, and I can update the bug once you're in.
> >>
> >
> > I will, though I'll need a bug ID for it. I presume tl is ok as
> > the
> > forest to use?
>
> This going into 8? T
- Original Message -
> - Original Message -
> >
> > >> Will you be putting this back yourself? If so let me know when
> > >> you
> > >> go
> > >> in, and I can update the bug once you're in.
> > >>
> > >
> > > I will, though I'll need a bug ID for it. I presume tl is ok as
> >
- Original Message -
> It's now marked as resolved.
>
> Thanks,
>
> Brad
>
Great. Thanks! Glad to get this finally resolved.
I'll let it promote through to 8, then suggest it for 7u.
>
> On 9/27/2012 9:58 AM, Andrew Hughes wrote:
The PKCS11 provider has an option in its configuration file,
"handleStartupErrors"
that can be used to make different types of failure non-critical (throwing a
UnsupportedOperationException rather than a ProviderException). By default,
all failures are critical.
This option is not available for
ss it would have to assume
the presence of a system NSS install. It's one of those bugs that's
easy to reproduce when you know the system and JDK configuration, but
not just from a test :-)
> Thanks.
>
>
> On 7 Nov 2012, at 18:45, Andrew Hughes wrote:
>
> >
> > This change is very useful for distributions, though, since they
> > can
> > delete the directory when creating a source tarball for OpenJDK8,
> > and
> > the ECC implementation will be automagically disabled from the
> > build.
> >
> >> It
- Original Message -
> On 15/03/2013 12:55 PM, Andrew Hughes wrote:
> > - Original Message -
> >> On 15/03/2013 5:37 AM, Omair Majid wrote:
> >>> Hi,
> >>>
> >>> Updated webrev at:
> >>> http://cr.openjdk.
On Tue, 30 Oct 2018 at 18:00, Martin Balao wrote:
>
> Hi,
>
> You're right, this is not relevant for a test.
>
> * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.01
> * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.01.zip
>
> Thanks,
> Martin.-
>
> On Tue,
On Thu, 1 Nov 2018 at 15:41, Martin Balao wrote:
>
> Hi Andrew,
>
> Thanks for having a look at this.
>
> Webrev.02 without "All rights reserved" and "affiliates" parts:
>
> * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.02/
> * http://cr.openjdk.java.net/~mbalao/webrevs/821
On 22/06/2020 10:00, Andrew Haley wrote:
> On 18/06/2020 19:33, Martin Balao wrote:
snip...
>> * L3724
>>* The last argument of 'sub' has type 'int', while in the not-Windows
>> variant is a long. Can we align this?
>
> We should do that, yes. Better it be long everywhere.
>
Patch looks
Bug: https://bugs.openjdk.java.net/browse/JDK-8196952
Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8196952/webrev.01/
Review thread: N/A
When merging the recent 8u161 update into IcedTea, I came across
a merge issue related to the ordering of changes to DSAParameterGenerator.
It's an issue
On 22 February 2018 at 14:38, Seán Coffey wrote:
> Thanks for looking at this one Andrew. I've had it on my to-do list.
>
> The patch looks fine.
>
> Regards,
> Sean.
>
Thanks. I had the patch around from fixing it in OpenJDK 7 so thought I may
as well post it.
Pushed: http://hg.openjdk.java.net
On 12:23 Tue 20 Apr , Severin Gehwolf wrote:
> Hi,
>
> Please review this OpenJDK 8u backport of the certificate_authorities
> extensionj. The OpenJDK 11u patch didn't apply cleanly after path
> unshuffeling, but was fairly trivial to resolve. Conflicts caused by:
>
> 1. X509Authentication.ja
32 matches
Mail list logo
