From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1683 invoked from network); 22 Jun 2023 14:46:07 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 22 Jun 2023 14:46:07 -0000 Received: (qmail 1797 invoked by uid 550); 22 Jun 2023 14:46:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1761 invoked from network); 22 Jun 2023 14:46:02 -0000 Date: Thu, 22 Jun 2023 10:45:50 -0400 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com Message-ID: <20230622144550.GN4163@brightrain.aerifal.cx> References: <20230621213746.GM4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] [RFC] trap on invalid printf formats On Thu, Jun 22, 2023 at 04:35:54PM +0200, Markus Wichmann wrote: > Am Wed, Jun 21, 2023 at 05:37:49PM -0400 schrieb Rich Felker: > > Inspired by a new instance of some bitrotted software using %Lu > > instead of %llu, attached is a draft patch to catch such errors rather > > than silently leaving missing output. > > > > Ah, it's the old dichotomy: For developers, this is nice, since it > catches bad behavior in a way that is impossible to ignore. For users, > this is horrible, since it crashes bad applications, maybe just before > they could save their data. And making the behavior selectable is > probably not sensible. > > As I count myself among the former group, I do support this move. But > then, I do not run a distro, and the only computer I am responsible for > is my own. Even for users, I'm not so sure of that. The distinction is potentially between crashing while writing out a new file containing corrupted data before rename()ing it over the old file, and silently succeeding then rename()ing the corrupted file over the old file. (Note that this is only silent if you don't check for errors, but if anyone using invalid formats were checking for errors, it seems these errors would necessarily have been reported. Unless they just check ferror() at the end, and we're not setting the FILE error flag on format string errors...which we probably should do if we don't switch to trapping.) FWIW I don't think there are a lot of these cases left in the wild at all, but I'm not sure. it might be nice to do some distro-wide testing with this patch applied (which is what I had in mind posting it) and see if any problems are caught before really considering whether to pursue upstreaming it. Rich