At 04:13 PM 2/15/2013, Chris Hegarty wrote:
>Mike,
>
>The issue you are describing exists both before and after Marks proposed
>patch. I am somewhat sympathetic to it, but it is outside the scope of what
>this issue is trying to address.
>
>Since the code is open ;-) you can of course propose a
Mike,
The issue you are describing exists both before and after Marks proposed patch.
I am somewhat sympathetic to it, but it is outside the scope of what this
issue is trying to address.
Since the code is open ;-) you can of course propose a separate patch, but I
don't think it should preven
Heh. You and I have a different understanding of silent! I meant that the
base64 decoder doesn't actually complain if the base64 is malformed by either
the insertion of extraneous characters, or by the omission of the ending pad
characters if any.
Later, Mike
At 12:22 PM 2/15/2013, Xuemin
At 11:57 AM 2/15/2013, Chris Hegarty wrote:
>Mike,
>
>I believe that Marks changes are a like for like replacement with what was
>there before, only using a supported public API. Are you saying otherwise? Or
>have you identified another potential issue?
I ran into this problem when trying to do
On 2/15/13 8:52 AM, Michael StJohns wrote:
Is the "mime" variant of Base64 the correct one for this? I ask because that variant ignores
extraneous characters rather than throwing an error on decode. Also, reading the code for the Base64
implementation, it silently "fixes" the case where ther
nitpicks
(1) personally I prefer the "commented out" one-line code, don't see the
value-add
of storing it into "base64EncodedCertString"
//out.println(Base64.getMimeEncoder().encodeToString(encoded));
(2) X509Factory.java:
Wouldn't it be more reasonable if the "data" was byte[]?
Mike,
I believe that Marks changes are a like for like replacement with what
was there before, only using a supported public API. Are you saying
otherwise? Or have you identified another potential issue?
-Chris.
On 15/02/2013 16:52, Michael StJohns wrote:
Is the "mime" variant of Base64 the
Is the "mime" variant of Base64 the correct one for this? I ask because that
variant ignores extraneous characters rather than throwing an error on decode.
Also, reading the code for the Base64 implementation, it silently "fixes" the
case where there are missing padding "=" characters. Neith
Hello Mark,
Your changes look fine to me. Just a few minor comments:
- PKCS10.java l.296:
the commented line seems better than the 2 proceeding lines
- keytool/Main.java l.358, SignatureFile.java l.35:
superfluous line
On 14 Feb 2013, at 13:24, Mark Sheppard wrote:
> Hi,
> as part of a
This looks good to me Mark, some minor comments:
- in places you you have imported java.util.Base64, where java.util.*
is already imported. Or you may need to slot the new import along
with other java.util. imports.
- Personally I would go with the NoCloseWrapperOutputStreamwrapper,
rather
Hi,
as part of a refactoring of the jdk codebase to use the base64
capabilities of java.util.Base64, the following modifications,
as per the webrev,
http://cr.openjdk.java.net/~chegar/8006182/webrev.00/
have been made to complete task JDK-8006182.
Could you oblige and review these changes
11 matches
Mail list logo
