From: Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "J.P." <jp@neverwas.me>
Cc: "Damien Cassou" <damien@cassou.me>,
"Björn Bidar" <bjorn.bidar@thaodan.de>,
emacs-erc@gnu.org, "Michael Albinus" <michael.albinus@gmx.de>,
58985@debbugs.gnu.org
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 [thread overview]
Message-ID: <87sfirjkjw.fsf__39812.5268447743$1668068542$gmane$org@disroot.org> (raw)
In-Reply-To: <87a64zo01q.fsf@neverwas.me> (J. P.'s message of "Wed, 09 Nov 2022 21:23:13 -0800")
[-- Attachment #1: Type: text/plain, Size: 4395 bytes --]
"J.P." <jp@neverwas.me> writes:
> Hi Akib,
>
> Akib Azmain Turja <akib@disroot.org> writes:
>
>> Michael Albinus <michael.albinus@gmx.de> writes:
>>
>>> "J.P." <jp@neverwas.me> 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-search".
>>
>> 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.
>
>
>
--
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."
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2022-11-10 8:11 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87wn8cb0ym.fsf@neverwas.me>
2022-11-05 23:55 ` bug#58985: 29.0.50; Have auth-source-pass behave more like other back ends J.P.
2022-11-06 11:23 ` Michael Albinus
[not found] ` <87pme09vis.fsf@gmx.de>
2022-11-07 5:00 ` J.P.
[not found] ` <87a653z7dl.fsf@neverwas.me>
2022-11-07 10:33 ` Michael Albinus
[not found] ` <874jvbnje1.fsf@gmx.de>
2022-11-08 13:56 ` J.P.
2022-11-10 0:39 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 5:25 ` J.P.
[not found] ` <875yfnnzy6.fsf@neverwas.me>
2022-11-10 13:40 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 14:40 ` J.P.
[not found] ` <87pmduc1pz.fsf@neverwas.me>
2022-11-15 3:45 ` J.P.
2022-11-09 18:25 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <874jv8ouh9.fsf@disroot.org>
2022-11-10 5:26 ` J.P.
2022-11-10 7:12 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <878rkjl1vd.fsf@disroot.org>
2022-11-10 14:38 ` J.P.
2022-11-11 3:17 ` J.P.
[not found] ` <877d026uym.fsf@neverwas.me>
2022-11-11 14:45 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87tu35eehq.fsf@disroot.org>
2022-11-12 4:30 ` J.P.
[not found] ` <87bkpcu74w.fsf@neverwas.me>
2022-11-12 15:24 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <875yfkdwlm.fsf@disroot.org>
2022-11-13 7:26 ` Akib Azmain Turja
2022-11-13 15:29 ` J.P.
[not found] ` <875yfiq3d8.fsf@neverwas.me>
2022-11-14 6:50 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87mt8uvxkp.fsf@disroot.org>
2022-11-14 15:12 ` J.P.
2022-11-14 17:49 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-15 3:32 ` J.P.
[not found] ` <87a64s99ka.fsf@neverwas.me>
2022-11-18 14:14 ` J.P.
2022-11-18 23:25 ` Kai Tetzlaff
2022-11-19 0:35 ` J.P.
2022-11-19 1:02 ` Kai Tetzlaff
2022-11-19 3:39 ` J.P.
2022-11-19 4:08 ` J.P.
2022-11-19 14:59 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87bkp4z6xg.fsf@neverwas.me>
2022-12-07 14:30 ` J.P.
2022-11-09 18:21 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <878rkkoup4.fsf@disroot.org>
2022-11-10 5:23 ` J.P.
2022-11-10 7:12 ` Akib Azmain Turja
[not found] ` <87a64zo01q.fsf@neverwas.me>
2022-11-10 8:11 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-11-06 14:39 ` Damien Cassou
2022-11-07 4:59 ` J.P.
2022-11-03 13:51 J.P.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='87sfirjkjw.fsf__39812.5268447743$1668068542$gmane$org@disroot.org' \
--to=bug-gnu-emacs@gnu.org \
--cc=58985@debbugs.gnu.org \
--cc=akib@disroot.org \
--cc=bjorn.bidar@thaodan.de \
--cc=damien@cassou.me \
--cc=emacs-erc@gnu.org \
--cc=jp@neverwas.me \
--cc=michael.albinus@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).