From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 8568D1F4B4 for ; Tue, 29 Sep 2020 00:44:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727134AbgI2Aou (ORCPT ); Mon, 28 Sep 2020 20:44:50 -0400 Received: from cloud.peff.net ([104.130.231.41]:43914 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725272AbgI2Aou (ORCPT ); Mon, 28 Sep 2020 20:44:50 -0400 Received: (qmail 6958 invoked by uid 109); 29 Sep 2020 00:44:50 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Tue, 29 Sep 2020 00:44:50 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 13658 invoked by uid 111); 29 Sep 2020 00:44:49 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Mon, 28 Sep 2020 20:44:49 -0400 Authentication-Results: peff.net; auth=none Date: Mon, 28 Sep 2020 20:44:48 -0400 From: Jeff King To: Junio C Hamano Cc: Carlo Arenas , Nikita Leonov via GitGitGadget , git@vger.kernel.org, Johannes Schindelin , Nikita Leonov Subject: Re: [PATCH v2 2/3] credentials: make line reading Windows compatible Message-ID: <20200929004448.GD898702@coredump.intra.peff.net> References: <20200929003000.GA898702@coredump.intra.peff.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, Sep 28, 2020 at 05:41:14PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I think that: > > > > - we'd never write a raw CR ourselves, as we'd urlencode the character > > > > - if somebody did put in a raw CR manually like: > > > > https://example.com\r\n > > > > then we'd currently fail to match "example.com". Which is probably > > not what they wanted. I suspect that \r in a hostname is bogus > > anyway (certainly curl will complain about it). > > I may be misremembering, but an argument I recall against the kind > of change we are dicussing now was that we ignore such an entry > right now, and the user may have added an entry for the host anew, > possibly with a more recent password. Changing the parsing to > ignore CR would silently resurrect such a stale entry that the user > has written off as unused, and depending on the order of entries in > the file, a site that used to work may start failing suddenly. Yeah, that is probably what would happen. I have to admit that it's such an obscure case that I'm not sure I really care. It's unlikely in practice, and if somebody did report such a case, I think my first response would be "well, why did you have a broken entry stuck in your file?". > I still don't see why we need to touch the cache-daemon, though. Yeah, I touched on that more in another response. -Peff