From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC Date: Thu, 21 Apr 2022 06:21:59 -0700 Message-ID: <87v8v2o9l4.fsf__15316.0042873182$1650547761$gmane$org@neverwas.me> References: <875yzakzvi.fsf@neverwas.me> <87bkxaeyuw.fsf@neverwas.me> <87zgkisetn.fsf@cassou.me> <87ee1ucvv3.fsf@neverwas.me> <87tuaqs9br.fsf__15054.4815858424$1650295523$gmane$org@cassou.me> <87k0bmbage.fsf@gmx.de> <878rrz268v.fsf@neverwas.me> <87czha3oc5.fsf_-_@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1616"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Damien Cassou , 48598@debbugs.gnu.org, Ted Zlatanov , emacs-erc@gnu.org, Sam Steingold To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 21 15:29:13 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhWrw-0000Cf-Ts for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Apr 2022 15:29:13 +0200 Original-Received: from localhost ([::1]:55910 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhWrv-00078o-My for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Apr 2022 09:29:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58718) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhWly-0007B6-Pb for bug-gnu-emacs@gnu.org; Thu, 21 Apr 2022 09:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54805) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nhWly-0000wa-Gk for bug-gnu-emacs@gnu.org; Thu, 21 Apr 2022 09:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nhWly-0002jl-Dk for bug-gnu-emacs@gnu.org; Thu, 21 Apr 2022 09:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Apr 2022 13:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48598 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 48598-submit@debbugs.gnu.org id=B48598.165054733110431 (code B ref 48598); Thu, 21 Apr 2022 13:23:02 +0000 Original-Received: (at 48598) by debbugs.gnu.org; 21 Apr 2022 13:22:11 +0000 Original-Received: from localhost ([127.0.0.1]:48702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhWl8-0002iA-Tp for submit@debbugs.gnu.org; Thu, 21 Apr 2022 09:22:11 -0400 Original-Received: from mail-108-mta179.mxroute.com ([136.175.108.179]:44079) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhWl7-0002hx-Nu for 48598@debbugs.gnu.org; Thu, 21 Apr 2022 09:22:10 -0400 Original-Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultrusercontent.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta179.mxroute.com (ZoneMTA) with ESMTPSA id 1804c4970dc000fe85.002 for <48598@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Thu, 21 Apr 2022 13:22:03 +0000 X-Zone-Loop: 5b35f9351ad41cb56d78295e025ac97b05e61dfe2033 X-Originating-IP: [140.82.40.27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+oymPVrG5HG6edyjJW3h3kNcKt0Dn94nypBJiGD7lCo=; b=ZXeoYpSLjXEB9VMFn1uVBDlSDa k0hnjnZlqV4UXuB5+IeRVK/z76j2/Ckd4fwIp/kd+HzsD7k/Kbxl1NvI9KctNGO2E75SBVN190YJ7 OJeg+j//Yv0DzDNjJCkkGat6GbaOguYJp5zPdQrCnUFyqeSYziw2juEH0rv+oq409jUmxJgm7KN33 ie20sLIleEb+QqUZDShZ752wxmwJN0CRNyv3lJkFASgbpcLUtw5L6lzPYdib9PPQTq9HyX53S0ZuN c9Z82ALNpzPu+rJpqnGLIc+/LCaJnycs0mg1WhWvAt7tx8D2lwQB/TV417CzDPSqVle1eg4in1Umh YH1rNb3Q==; In-Reply-To: <87czha3oc5.fsf_-_@gmx.de> (Michael Albinus's message of "Thu, 21 Apr 2022 09:08:58 +0200") X-AuthUser: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:230364 Archived-At: Hi Michael, Michael Albinus writes: > Btw, I found it hard to scan a bug report with so many different > problems. Usually, it is more simple to discuss every problem in a > separate bug report, in order not to lose control. Except, all of them > are strongly dependent. Thanks for the thorough remarks, and apologies for the "omnibus" bug report. I have others pending as well that are actually subsets of this one, and I really should have done likewise for all this auth-source business (filed a new, "interdependent" report, that is). Next time, let's hope I'll be more thoughtful about it. > You have said somewhere there is an archive at > . I cannot access > this URL. Is there another URL to be used? Sorry for the confusion. That's a package.el-only endpoint without any browsable HTML, i.e., (push '("erc-tools" . "https://jpneverwas.gitlab.io/erc-tools/archive/") package-archives) For future reference, the full patch set is available for browsing here: https://git.neverwas.me/repos/erc-tools/tree/bugs/48598/patches/wip And is downloadable here: https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz >> While it may be tempting to single out pass, this part from the doc >> string for `auth-source-search' says that ignoring :max and returning at >> most one result is totally acceptable: >> >> :max N means to try to return at most N items (defaults to 1). >> More than N items may be returned, depending on the search and >> the backend. > > Indeed. In Tramp there are two calls of auth-source-search: One call in > order to retrieve the password, and there I use ':max 1' explicitly (see > `tramp-read-passwd'). And there is another function used for user/host > name completion, not looking for the password, and there I use ':max > most-positive-fixnum' (see `tramp-parse-auth-sources'). But the former > case could refrain from specifying :max. Wow, so my lack of communications skills strikes again! What I meant to say was that from my reading of that doc string (basically the de facto compliance spec), a *back end* ignoring :max is fair game. But I think the way I wrote it gave the misleading impression I was saying fair game from the querying client's perspective. But regardless, the tramp examples are indeed helpful. So, thanks for those. > Making auth-source-pass conform to the auth-source API would always be a > good thing=E2=84=A2. I don't know whether there exist already such a bug = report, > otherwise I recommend you to write a new report. Agreed. Unless Ted or Damien have anything to add, I'm going to remove support for pass from this patch series (at least for now, even though my terrible hacks seem to make it gel well enough). I'll later open a new bug report asking for clarification on the interface and possibly include a patch for making auth-source-pass :max aware. > Just follow the usual recommendation for ERT tests: make a temporary > environment for the test (for example, create a temporary > auth-source-pass store), run your test, remove test data (for example, > remove the temporary auth-source-pass store). That's how the tests in > auth-source-tests.el and auth-source-pass-tests.el are designed, IIRC. > > Since you don't want to test auth-source-pass functionality explicitly, > you can of course use any other auth-source backend. The scenario is the > same, and you could even provide several test functions like > erc-tests--auth-source-netrc, erc-tests--auth-source-json, and alike. Makes total sense. I believe I've ticked most of those boxes already (having used auth-source-tests.el as a reference, as you wisely recommend). I should have excerpted that work for highlighting instead of dropping another biggish patch in that last email. Anyway, here is the relevant file (in case you're curious), which I believe reflects the approach you describe: https://git.neverwas.me/repos/erc-v3/tree/test/erc-services-tests.el?id= =3D00ad7115#n468 >> Currently, results are narrowed to the best candidate, and its >> secret is returned as a string for (relatively) immediate >> transmission. IOW, I don't think any obvious references to the >> discarded ones remain, if that matters. > > That sounds OK. Even better would be to use functions for the :secret > token, instead of the secret strings themselves. And call that function > when you need it. Right, currently, outgoing messages are fully baked out before being enqueued, and the queue itself is fully accessible. Keeping those quasi thunks around would make more sense to prevent accidental leakage when printing debug info and dumping to I/O logs. But that would require some real redesign, which will become easier after a few ponderous deprecations mature, so perhaps by Emacs 30. Anyway, I can't thank you enough for taking the time to look at this stuff. Definitely obliged. J.P.