Re: bug#58985: 29.0.50; Have auth-source-pass behave more like other back ends

Akib Azmain Turja <[email protected]> Mon, 14 Nov 2022 12:50:46 +0600
Newsgroups	gmane.emacs.erc.general
Message-ID	<[email protected]>
"J.P." <[email protected]> writes:

> Akib Azmain Turja <[email protected]> writes:
>
>> Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife
>> of text editors" <[email protected]> writes:
>>
>>> "J.P." <[email protected]> writes:
>>>
>>>> While I certainly welcome the assiduous scrutinizing of Emacs lisp
>>>> mechanics and technique (truly), I was mainly hoping that, as an avid
>>>> pass user, you would also help flesh out the precise effects of the
>>>> behavior introduced by these changes and hopefully share some insights
>>>> into how they might impact day-to-day usage for the typical pass user.
>>>> Granted, that necessarily involves applying these patches atop your
>>>> daily driver and living with them for a spell and, ideally, investing
>>>> some thought into imagining common usage patterns beyond your own (plus
>>>> any potentially problematic edge cases). If you have the energy to
>>>> devote to (perhaps just some of) these areas, it would really help move
>>>> this bug report forward. Thanks.
>>>
>>> Actually, I'm not very brave, and any damage to my password-store would
>>> be an absolute disaster.
>>>
>>> However, I have made a backup and add the encrypted passwords to a Git
>>> repository, and since the patch looks safe, I'm going to apply and test
>>> it.
>>
>> I have applied the patch the on top commit f8c11b5a, and it works fine.
>>
>> I did some basic testing (manually) of auth-source-pass and the
>> dependent packages I use, password-store and pass, and they all seem to
>> be unaffected when the new option enabled.  So I guess we can enable it
>> by default.  I didn't felt the need of test with the new feature
>> disabled, since the patch doesn't touch any old code.
>
> Awesome. Thanks for all the work. I know it's kind of a hassle.
>
>> And I also found that, auth-source finds the entry "[email protected]"
>> correctly with (auth-source-search :host "disroot.org") when the new
>> user option is set to t.
>
> Yeah, it's sometimes tricky to tell if the new code is even running, so
> it's great that you checked that.

I'm pretty sure the new code was running, since I set
auth-source-do-cache to nil to disable cache prior doing the tests.

>
>> However, I haven't still installed the Emacs build with the patch
>> applied as my daily driver, I'm working on that.  The tests were
>> performed on Emacs build without GUI.
>
> OK, nice.
>
> You mentioned previously some potentially surprising ambiguities
> surrounding the trailing /user syntax. If any realistic scenarios
> present themselves, perhaps we can try to improve the situation if it's
> not too far out of scope (or just document the behavior, maybe in a unit
> test). Thanks again.

I think it's good enough to install on master.  Then more people can
test and report about it.

However, observed some behavior of the new code, here are my findings:

The new searching code seems to prefer "HOST/USER" over "USER@HOST".

I created the password store entry "foo.com/bar.org".  Then I evaluated:
(warning: manually typed with hands)

(auth-source-search :host "bar.org")
;; => nil

(auth-source-search :host "foo.com")
;; => ((:host "foo.com" :user "bar.org" :secret ...))

I created another entry "[email protected]".  But it returns the password
in "foo.com/bar.org".

I deleted "foo.com/bar.org", now it return the password of
"[email protected]".

I created "foo.com/bar.org" again, and "foo.com/bar.org" is preferred
again.

I suggest to prefer the "@" syntax over "/user" syntax.

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: [email protected]
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."
signature.asc (application/pgp-signature, 832 B)