From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3256 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Tue, 30 Apr 2013 10:35:16 +0200 Message-ID: <20130430083516.GK12689@port70.net> References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130426005545.GA7923@Caracal> <20130429101620.GG12689@port70.net> <20130429215500.GJ12689@port70.net> <20130430021014.GC20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367310931 18768 80.91.229.3 (30 Apr 2013 08:35:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Apr 2013 08:35:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3260-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 30 10:35:31 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UX626-0000xU-7Q for gllmg-musl@plane.gmane.org; Tue, 30 Apr 2013 10:35:30 +0200 Original-Received: (qmail 8093 invoked by uid 550); 30 Apr 2013 08:35:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 8084 invoked from network); 30 Apr 2013 08:35:28 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3256 Archived-At: * Gregor Pintar [2013-04-30 08:32:26 +0200]: > My idea was that program would be correct, if it inputs too much data > to hash function. It is very cheap to implement in most algorithms > (detect counter overflow). Otherwise program has to count it himself. i dont think the program has to count eg in case of sha1 if you know that the throughput is less than 10gbps then it takes more than 50years to overflow in theory there might be use-cases where the overflow could occure in which case reporting error makes sense, but it seems to me that can be avoided by the proper choice of algorithm or reasonable application design of course if you allow configurability of the block size and rounds etc then the overflow becomes a practical concern so the error is justified, which is why i said that flexibility is not necessarily a good thing (general interface requires general error handling) > However, in most cases it is too late to handle correctly when it > already fails. Not returning error on too much input or output could > silently cause incorrect usage. Using assert might be better idea > since at that point it is fatal anyway, but that would cause data > leak, unless program would catch SIGABRT (it should others like SIGINT > anyway) and wipe data, but that requires all sensitive data in program > is global. i'd let the user do the bad thing (silently overflow) if it matters it can be designed around in the application