From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#58985: 29.0.50; Have auth-source-pass behave more like other back ends Date: Thu, 10 Nov 2022 14:11:31 +0600 Message-ID: <87sfirjkjw.fsf__39812.5268447743$1668068542$gmane$org@disroot.org> References: <87wn8cb0ym.fsf@neverwas.me> <874jvdardn.fsf__3771.40490324877$1667692584$gmane$org@neverwas.me> <87pme09vis.fsf@gmx.de> <878rkkoup4.fsf@disroot.org> <87a64zo01q.fsf@neverwas.me> Reply-To: Akib Azmain Turja Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40772"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Damien Cassou , =?UTF-8?Q?Bj=C3=B6rn?= Bidar , emacs-erc@gnu.org, Michael Albinus , 58985@debbugs.gnu.org To: "J.P." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 10 09:22:14 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 1ot2pB-000AMF-LR for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Nov 2022 09:22:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ot2p4-0005FZ-TG; Thu, 10 Nov 2022 03:22:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ot2p0-0005E8-SB for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2022 03:22:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ot2oz-0002u8-VE for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2022 03:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ot2oz-0002Va-QZ for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2022 03:22:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Akib Azmain Turja Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Nov 2022 08:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58985 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 58985-submit@debbugs.gnu.org id=B58985.16680684839583 (code B ref 58985); Thu, 10 Nov 2022 08:22:01 +0000 Original-Received: (at 58985) by debbugs.gnu.org; 10 Nov 2022 08:21:23 +0000 Original-Received: from localhost ([127.0.0.1]:41811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ot2oN-0002UV-9R for submit@debbugs.gnu.org; Thu, 10 Nov 2022 03:21:23 -0500 Original-Received: from knopi.disroot.org ([178.21.23.139]:52434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ot2oL-0002UM-3s for 58985@debbugs.gnu.org; Thu, 10 Nov 2022 03:21:22 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id B176740F3C; Thu, 10 Nov 2022 09:21:19 +0100 (CET) X-Virus-Scanned: SPAM Filter at disroot.org Original-Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP9W6rV6TPGh; Thu, 10 Nov 2022 09:21:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1668068478; bh=QlI8gSuiRwVrfKTVGiCPXLJl3BOHHNzAWw4l61QDVus=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Dhk9xCWTkHmEk7LYgtRUk5BaKUbGvxNzuwJpaFfkTtTnlzGezR9SdHGV1N2WQAhlv cY4B2gS8ekJEu26/v/Oej7Dh/75RyVQRQKxas6tXvjvW/F4oMIk4lXMQP7IfOni5Os z/3de6mF2FPqY1Ee+Eb4pkmQ6luP8QgUMGnDmmB4gRdFm5Ik+ihpV6X2QIrTZ7sg8u wAUBplMgIIhZEn+BmlGhyqeKsW66t0WluX/AewIPqIJ3LqMQw+RFU7DYioK3og4vpa SxD9iiBt3UGeRoDPaRuBl+6bYBt5qKS2mqT15JzRu9ZO5E3ekVRID95EFB+rnWnnup h3BmTGUAlhlnA== In-Reply-To: <87a64zo01q.fsf@neverwas.me> (J. P.'s message of "Wed, 09 Nov 2022 21:23:13 -0800") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:247492 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable "J.P." writes: > Hi Akib, > > Akib Azmain Turja writes: > >> Michael Albinus writes: >> >>> "J.P." writes: >>> >>> Hi, >>> >>>> v2. Respect existing user option. >>> >>> I'm not familiar with the auth-source-pass.el implementation, so I >>> cannot speak too much about your patch. Reading it roughly, I haven't >>> found serious flaws, 'tho. >> >> It has a serious flaw AFAIK. I have a password entry >> "akib@disroot.org", and this legitimate search query doesn't find it: >> >> (auth-source-search :host "disroot.org") >> >> But if specify the user, it finds the entry: >> >> (auth-source-search :host "disroot.org" :user "akib") > > Hm, that's unfortunate. I specifically added a pair of tests just for > this, namely > > auth-source-pass-extra-query-keywords--netrc-akib > auth-source-pass-extra-query-keywords--akib > > Are you able to pinpoint why they're reporting a false positive by any > chance (or give a minimal repro recipe with an FS tree layout of some > ~/.password-store)? Also, and I'm not trying to be insulting here, but > did you remember to rerun Make after applying the patch(es)? > Actually, I didn't review the patches in this email, I just commented on the auth-source-pass in the master *right now*, not the patch. Sorry for the trouble. >> And the entries can also be ambiguous. For example, the entry at path >> "foo.org/bar.net" might be interpreted as the password of bar.net, or >> as the password of the user "bar.net" on "foo.org". The current >> implementation seems to interpret such entries unpredictably. > > Sounds convincing. What do you think about deprecating the /user form? > (This may have to be spun off into a separate bug report.) > > At the end of the day, I'm more concerned about consistency (and thus > predictability) than anything. IOW, I'd be okay with "foo.org/bar.net" > being parsed either way, as long as it's the *same* way every time, > which we could then document. If you're indeed finding otherwise, please > provide an MRE for this as well (with patches applied, of course). > >>> - The name of this user option as well as its docstring are focussed on >>> the current behavior. People won't know what "mimic other auth-source >>> backends" would mean. Please describe the effect w/o that comparison, >>> and pls give it a name based on its effect, and not "...-standard-sea= rch". >> >> I agree. This variable should be something like >> "auth-source-pass-old-search" (or even "...-obsolete-search"). > > Wait, but `auth-source-pass-old-search' sounds like we're regressing to > describing a comparison rather than an effect. The name in the second > (v2) iteration, `auth-source-pass-extra-query-keywords', was an attempt > to rein in the scope of the option and convey no more than what it's > claiming to offer. Thanks for clarification. I have written the same thing in my another (actual) patch review email, feel free to ignore those parts. > >> And the default should be nil, because it fixes many bugs, and it's >> pointless to disable the fixes by the default. > > Not sure I agree here, even though Damien seems to be in accord. In the > interest of minimizing churn for Melpa's pass and password-store > packages, I'd rather make this an opt-in for Emacs 29 if we end up > including it at all. > How about communicating with them? >>> - I'm missing the documentation in doc/misc/auth.texi and etc/NEWS. >> >> What documentation? Of this change or anything else? I think we should >> focus on the implement before writing documentation. > > Hm, (again, not trying to insult here, but) did you somehow miss the > patches attached to the email you replied to? It kind of looks that way > based on your comments. If I'm wrong, though, please forgive; I > appreciate your input regardless. Yeah, you are right, I didn't notice those patches and just commented on the auth-source-pass in the master *right now*, not the patch. Please forgive for the trouble. > > Thanks, > J.P. > > > =2D-=20 Akib Azmain Turja --- https://akib.codeberg.page/ GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social, Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyVTKmrtL6kNBe3FRVTX89U2IYWsFAmNssjQACgkQVTX89U2I YWu69BAAn/nMR72vNbOvdeE0TOhpwY6jfaFHiEcg+jkOPzz7xPs/elLkMy+sLoYk Sq/ckk22BAgPQw+p7Ryx31XPGTHarS9gfShFjk5Dq1QZfFrUzAiCZuKUWgnmWUiP Mm09lMTEvBnyRQMr75y46OVO4/NwXjnOuuAxQvSoJuBgVkJKgZbQUcbBLgu9yaY+ m8H8detjrxsFldb8y3vK06HNEQo+kZYKlreZ/c8Y8whkfJTjvpyI7tZq7laR4Ikq zoB54YwGRcYZO5JngvoX2sAKhy6AdpD9zK6eRW4RCtiB2wfD0PTumr/Un53VOOt7 QgLG8q32yLwoprNcfNhbDamj6yJ+dFNj7ShGc1rkE8qnYggz7N1CznzDkMRgCfLm QJSnDE3laAGqFdfKCEgfyjrj36Mn4l27dQHyMHZExAFWTqly+VsiGOwTMQfHHLsP k98SLuU6qXVvVH29uHBboU+G9ttZl/4N1UPiAp+BYdVaxkXgZxUASHsmjQ1GoHKI n1wDvlpfcj6dsuO2RtJmiDtMq188lmJYTkkUwvdFKzuMxP7j7ajXi0LupWHPUNH5 Sul6Qli80zsk5PrP9W6dQDANhl/2nBfR2qls9uezaAYDkMceDRgBsIksDxqbRdDh HXtMbwPen0IlinMvO5Kp2EZwL4eQucThbk60zAUtlASt8E6EkqU= =1WOw -----END PGP SIGNATURE----- --=-=-=--