From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#57956: 29.0.50; Add minimal authorization support to sasl-scram-rfc Date: Fri, 23 Sep 2022 13:37:19 +0000 Message-ID: <875yheus8g.fsf__49445.6146306888$1663940301$gmane$org@posteo.net> References: <871qs62o0y.fsf@neverwas.me> <87tu52awv9.fsf@gnus.org> <87a66ssw7s.fsf@neverwas.me> <871qs4mv7a.fsf@posteo.net> <875yhggc5s.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27454"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 57956@debbugs.gnu.org, Magnus Henoch , emacs-erc@gnu.org To: "J.P." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 23 15:38:12 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 1obise-0006vr-Ib for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Sep 2022 15:38:12 +0200 Original-Received: from localhost ([::1]:40474 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1obisd-00079Z-Fw for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Sep 2022 09:38:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53236) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1obisU-00079G-PY for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2022 09:38:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40619) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1obisU-0000ZG-HO for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2022 09:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1obisU-00064A-3W for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2022 09:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Sep 2022 13:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57956 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 57956-submit@debbugs.gnu.org id=B57956.166394026023286 (code B ref 57956); Fri, 23 Sep 2022 13:38:02 +0000 Original-Received: (at 57956) by debbugs.gnu.org; 23 Sep 2022 13:37:40 +0000 Original-Received: from localhost ([127.0.0.1]:39697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1obis8-00063V-9H for submit@debbugs.gnu.org; Fri, 23 Sep 2022 09:37:40 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:37945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1obis6-00063I-K0 for 57956@debbugs.gnu.org; Fri, 23 Sep 2022 09:37:39 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C772B240101 for <57956@debbugs.gnu.org>; Fri, 23 Sep 2022 15:37:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1663940252; bh=7hxgD1mBj46bjsowuAXrqMno15WflNNLtAv2Z7G8zvM=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=VQhEkFMeipDvzPBNk0HwgqSu+beSYlkKdbR+Q/DbHFBqCAbCRj/oSnS5Pfy1emRxl RjsVk6V8aK6fgkDYYLPlS7+aE+IsRO5CksxH+11lpQL4C6K44b+0UsZ6IjyVFx2hiE nmXn8R89oDvhd/YzHV3te37MQUIftDcMGZpRo3CZ4YysOb7IC9YH/E5n2ajmqgsnpk hVtbdkC55ygMEtqhYQkv+OzQDRL5mXfcV47CD1MbVKFvrkpqLk/VMbfkGdW2+R+bIT yKXjwp8xOni2Eg5nfLFb35mgtrfot7+6vzM8tfCAhzPjemgacAUXTIsAld2quU9v6s W4sr+mdfQCIJw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MYtVy40pgz6tmK; Fri, 23 Sep 2022 15:37:30 +0200 (CEST) In-Reply-To: <875yhggc5s.fsf@neverwas.me> (J. P.'s message of "Wed, 21 Sep 2022 23:23:43 -0700") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB 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:243462 Archived-At: "J.P." writes: > Philip Kaludercic writes: > >> "J.P." writes: >> >>> is obviously an internal function. Does that matter? Would you rather we >>> export it (as in rename it or alias it) beforehand (IOW, now)? >> >> I'd rather not add "internal functions" to Compat, at least in a way >> that it would be exposed as part of the official Compat interface. That >> being said, I am not familiar with the feature being discussed here, > > The feature (also a bug fix) being discussed here concerns the final > client-side step of the SCRAM protocol. Basically, it computes a > challenge from the server and packs the answer into an outgoing reply. > >> so maybe an exception has to be made? > > No reason to. We can keep it internal (the "final step" function, that > is) and backport its logic, its helpers, and all (two-ish?) public > functions that call it (I'm likely adding a third). There should be no issue with adding two or three functions to Compat. > Alternatively, we could > > - have ERC restrict this feature to users of Emacs 29+, or > - stick with the status quo and manage this particular case manually via > erc-comapt.el [1]. > > I'd be fine with any of the above, really. Do you think there is any interest in providing these functions outside of ERC? If so, I think adding the code to Compat ought to be fine.