Return-Path: X-Original-To: apmail-santuario-dev-archive@www.apache.org Delivered-To: apmail-santuario-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CFB1617B6C for ; Tue, 14 Apr 2015 14:02:26 +0000 (UTC) Received: (qmail 69117 invoked by uid 500); 14 Apr 2015 14:02:23 -0000 Delivered-To: apmail-santuario-dev-archive@santuario.apache.org Received: (qmail 69088 invoked by uid 500); 14 Apr 2015 14:02:23 -0000 Mailing-List: contact dev-help@santuario.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@santuario.apache.org Delivered-To: mailing list dev@santuario.apache.org Received: (qmail 69078 invoked by uid 99); 14 Apr 2015 14:02:23 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Apr 2015 14:02:23 +0000 Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 3CBC71A0113 for ; Tue, 14 Apr 2015 14:02:23 +0000 (UTC) Received: by wgin8 with SMTP id n8so13152518wgi.0 for ; Tue, 14 Apr 2015 07:02:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.186.5 with SMTP id fg5mr32638209wic.60.1429020141816; Tue, 14 Apr 2015 07:02:21 -0700 (PDT) Reply-To: coheigea@apache.org Received: by 10.28.149.194 with HTTP; Tue, 14 Apr 2015 07:02:21 -0700 (PDT) In-Reply-To: <13C102BC-DB48-42AF-95F6-AFD2648597C0@osu.edu> References: <13C102BC-DB48-42AF-95F6-AFD2648597C0@osu.edu> Date: Tue, 14 Apr 2015 15:02:21 +0100 Message-ID: Subject: Re: 2.0.4 release From: Colm O hEigeartaigh To: "dev@santuario.apache.org" Content-Type: multipart/alternative; boundary=001a11c334e6ee148b0513afad4c --001a11c334e6ee148b0513afad4c Content-Type: text/plain; charset=UTF-8 Ok cool. I'll call a vote tomorrow. Colm. On Mon, Apr 13, 2015 at 5:35 PM, Cantor, Scott wrote: > On 4/13/15, 9:56 AM, "Cantor, Scott" wrote: > > >On 4/13/15, 5:10 AM, "Colm O hEigeartaigh" wrote: > >> > >>I'll call a vote on a 2.0.4 Java release in a few days, so shout now if > there is anything else to go into it. > > > >I (or somebody from my project) may be filing a bug soon related to what > appears to be a regression in the RSA verify code that dates back a while > (probably to before 2.0.0). We're seeing signatures fail that a lot of > other tools are reporting are valid (the C++ library included). Seems to be > related to signature length and padding issues when the signature has 00 > bytes and ends up encoded as shorter than 256 bytes (for a 2048 bit key > anyway). > > I could have held my tongue and saved the time, but Ian says he's found > pretty clear spec language in the RFCs that indicate the Java code is > right, and everything else seems to be wrong, so false alarm. It does seem > that the old 1.4 Java code accepted these signatures, so apparently it was > a bug and was fixed. > > We don't think the false positives are a big thing since it's just > implicitly padding zeros probably, but it's not strictly correct. I'm going > to file a Santuario C++ bug and look into what OpenSSL's primitives are > doing. > > -- Scott > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com --001a11c334e6ee148b0513afad4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ok cool. I'll call a vote tomorrow= .

Colm.

On Mon, Apr 13, 2015 at 5:35 PM, Cantor, Scott <cantor.2@osu.e= du> wrote:
On 4/13/15, 9:56 AM, "Cantor, Scott" <cantor.2@osu.edu> wrote:

>On 4/13/15, 5:10 AM, "Colm O hEigeartaigh" <coheigea@apache.org> wrote:
>>
>>I'll call a vote on a 2.0.4 Java release in a few days, so shou= t now if there is anything else to go into it.
>
>I (or somebody from my project) may be filing a bug soon related to wha= t appears to be a regression in the RSA verify code that dates back a while= (probably to before 2.0.0). We're seeing signatures fail that a lot of= other tools are reporting are valid (the C++ library included). Seems to b= e related to signature length and padding issues when the signature has 00 = bytes and ends up encoded as shorter than 256 bytes (for a 2048 bit key any= way).

I could have held my tongue and saved the time, but Ian says he'= s found pretty clear spec language in the RFCs that indicate the Java code = is right, and everything else seems to be wrong, so false alarm. It does se= em that the old 1.4 Java code accepted these signatures, so apparently it w= as a bug and was fixed.

We don't think the false positives are a big thing since it's just = implicitly padding zeros probably, but it's not strictly correct. I'= ;m going to file a Santuario C++ bug and look into what OpenSSL's primi= tives are doing.

-- Scott




--
Colm O hEigeartaigh

Talend Community Coder
= http://coders.talend= .com
--001a11c334e6ee148b0513afad4c--