From owner-freebsd-current@freebsd.org Sun Dec 29 06:50:43 2019 Return-Path: <owner-freebsd-current@freebsd.org> Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 159C61D6993 for <freebsd-current@mailman.nyi.freebsd.org>; Sun, 29 Dec 2019 06:50:43 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47lrmf12SZz4CKQ for <freebsd-current@freebsd.org>; Sun, 29 Dec 2019 06:50:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id xBT6odR2069310 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 28 Dec 2019 22:50:39 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id xBT6od0m069309; Sat, 28 Dec 2019 22:50:39 -0800 (PST) (envelope-from sgk) Date: Sat, 28 Dec 2019 22:50:39 -0800 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Garance A Drosehn <drosih@rpi.edu>, freebsd-current@freebsd.org Subject: Re: OpenSSL breaks factor(6) Message-ID: <20191229065039.GA69227@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20191229051035.GA68947@troutmask.apl.washington.edu> <201912290534.xBT5YqVp046009@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201912290534.xBT5YqVp046009@gndrsh.dnsmgr.net> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47lrmf12SZz4CKQ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-2.23 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.23)[ip: (0.05), ipnet: 128.95.0.0/16(-0.26), asn: 73(-0.91), country: US(-0.05)]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/> List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sun, 29 Dec 2019 06:50:43 -0000 On Sat, Dec 28, 2019 at 09:34:52PM -0800, Rodney W. Grimes wrote: > > On Sat, Dec 28, 2019 at 10:46:52PM -0500, Garance A Drosehn wrote: > > > On 27 Dec 2019, at 17:42, 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. > > > > > > What if the user wants to factor a hexadecimal value which does not > > > happen to include [a...f]? > > > > > > How about recognizing a prefix of '0x' as a way to indicate the value > > > is hexadecimal? > > > > > > > An interested user will need to add that support. AFAIK, factor(6) > > has never recognized the 0x prefix, and I'm not trying to add new > > features. I'm simply fixing factor(6) to match its documentation, > > and trying to ensure WITH_OPENSSL and WITHOUT_OPENSSL give the > > same results where applicable. > > > > The logic is to first try to convert the string to a decimal if > > the leading digits are members of the set [0,...,9]. If this > > conversion fails, then try to convert the string as a hexadecimal > > number. A problem occurs because OpenSSL's BN_dec2bn does not fail > > for a number like '1abc' (converts it to 1) whereas the local > > implementation of BN_dec2bn fails during the conversion, and so > > the BN_hex2bn function is executed and '1abc' is converted. > > Wasnt the hex conversion undocumented? Yes, and I fixed the manpage to document the behavior. And, I fixed factor(6) to match the documentation in other aspects (e.g., leading '+' character). > Since it seems to have issues, and is of dubious value > might it might be best to just remove it? It has been a part of FreeBSD's factor since r104722 | fanf | 2002-10-09 That is 17 years. Are you sure no one is using this feature in some script? What about backwards compatibility? AFAICT, with my limited testing, my patch should fix the issues that I discovered. Do what you want with the patch (including ignoring it). Hopefully, someone in the FreeBSD project will now recognize that factor(6) with and without OpenSSL gives inconsistent results, and neither matches factor(6)'s manpage. -- Steve