Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Dec 2019 21:15:33 -0800
From:      Steve Kargl <sgk@troutmask.apl.washington.edu>
To:        "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
Cc:        freebsd-current@freebsd.org
Subject:   Re: OpenSSL breaks factor(6)
Message-ID:  <20191228051533.GA62606@troutmask.apl.washington.edu>
In-Reply-To: <201912280442.xBS4grnp041518@gndrsh.dnsmgr.net>
References:  <20191228035155.GA62416@troutmask.apl.washington.edu> <201912280442.xBS4grnp041518@gndrsh.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 27, 2019 at 08:42:53PM -0800, Rodney W. Grimes wrote:
> > On Fri, Dec 27, 2019 at 07:00:04PM -0800, Rodney W. Grimes wrote:
> > > > On Fri, Dec 27, 2019 at 01:47:17PM -0800, Steve Kargl wrote:
> > > >  
> > > > This patch now includes a fix for hexadecimal conversion.  It
> > > > simple scans the string for a hex digit in [a,...,f] and assumes
> > > > that a hexadecimal string has been entered.  A string that includes
> > > > character from the decimal digits is assumed to by a decimal
> > > > representation.  
> > > 
> > > It looks to me that the old code did the common method of
> > > try to convert as decimal, if that fails, try it as hex,
> > > if that fails report an error.
> > > 
> > > Why is is that this common logic no longer works?
> > 
> > AFAICT, BN_dec2bn and BN_hex2bn from OpenSSL scan from left
> > to right, does a conversion with what is possible, and reports
> > success.  That is, for 1abc, BN_dec2bn can convert 1 to 1 and
> > reports success.  The local implementations of these functions,
> > when OpenSSL is not used, does not do this partial conversion.
> 
> I think I see now, the local implementaton checks for whole
> string conversion with a test for newline or null as the last
> byte converted by strtoul, the OpenSSL does not do this.
> 

My patch fixes that.  The manpage documents that '1abcp' should
convert '1abc'.  The 'p' simply terminates the conversion.  The
local implementations actually flags an error.  I suspect the
logic never worked as intended.  The use of OpenSSL functions 
in factor(6) was introduced in r104722 by fanf@.

> So why ever use the, um, IMHO broken for this application,
> SSL versions of these functions?  Or if we do need to use
> them for some reason apply the whole string conversion
> checks as wrappers around them?

You'll need to ask fanf@, but I suspect the SSL version 
was introduced to allow the factoring of integers that
exceed (uint64_t)(-1).

-- 
Steve



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191228051533.GA62606>