From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Bj=C3=B6rn?= Bidar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#72441: 31.0.50; Auth-source-pass doesn't match password attributes or hosts without user when extra-query-keywords is true Date: Fri, 09 Aug 2024 22:20:24 +0300 Message-ID: <29291.1952639528$1723231321@news.gmane.org> References: <17083.4807607875$1722683645@news.gmane.org> <87frrdvaku.fsf@neverwas.me> Reply-To: =?UTF-8?Q?Bj=C3=B6rn?= Bidar 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="22549"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 72441@debbugs.gnu.org To: "J.P." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 09 21:21:53 2024 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 1scVBQ-0005jW-OX for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 09 Aug 2024 21:21:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1scVBB-00024L-QP; Fri, 09 Aug 2024 15:21:38 -0400 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 1scVB8-00023n-Rw for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2024 15:21:35 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1scVB8-0008OM-J8 for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2024 15:21:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=TRcQ8WxEZPgfl76ThJKtW5y/0aS+IWpMAYY70yNEOfA=; b=Ue/ZFZgFHYA6rbM4q15hMYIWpfy9FnPEtwKyJIfz3EqX16cCQ3pYKNZhJVGXlD4GVdDlcq4eEqI+sq5blKqjXDtUQmXcLjqjil3LE2O5//LLUmRzTGBRPUTnggvayDZhpJguRBTmtOdWrNiP5QR6LEliJRkECg9fxpgPVh6XbDp10ieC5I9FG45acxkWPng+uQ7Zzydg8GkAhyYZWAX2FyDzZ8TjRGwQnJ0oo/pB+72p1j17JmimpdcujotgPzchTKF5IAFjf8BEAGqiMFdbkTwaxcd1gNZVFlX/Wk/iqrE4JyQWdzoQrTI8dkFO7BqCw8xIsV7E1nKHYYHajlYMVg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1scVBZ-0002jd-Rd for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2024 15:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Bj=C3=B6rn?= Bidar Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2024 19:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72441 X-GNU-PR-Package: emacs Original-Received: via spool by 72441-submit@debbugs.gnu.org id=B72441.172323126610430 (code B ref 72441); Fri, 09 Aug 2024 19:22:01 +0000 Original-Received: (at 72441) by debbugs.gnu.org; 9 Aug 2024 19:21:06 +0000 Original-Received: from localhost ([127.0.0.1]:38614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1scVAf-0002i9-GP for submit@debbugs.gnu.org; Fri, 09 Aug 2024 15:21:06 -0400 Original-Received: from thaodan.de ([185.216.177.71]:51010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1scVAb-0002hV-H8 for 72441@debbugs.gnu.org; Fri, 09 Aug 2024 15:21:04 -0400 Original-Received: from odin (dsl-trebng12-50dc75-154.dhcp.inet.fi [80.220.117.154]) by thaodan.de (Postfix) with ESMTPSA id BF59CD00056; Fri, 9 Aug 2024 22:20:26 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1723231226; bh=VS6VjaMCeg7c3lWsTnOeEkSXoFWKGvoGJLNXae4SpbM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=m9Maj2PKiQO5OqG++6+DQjpaf2jMSQtK/EfpqHFc2pYRcKV/BdyEZxcPzyOVfxKMh z+IPek9bhCXO8PIx4vGXv8NTZL5b+QbIoBp/nWkDE4GW6E2rK7MVNtZ0AaqV2BzCmn ZP6uybnLqxChgCl5FbELYrWOpPSJMfBd569sEg/d/9p3FluLv64WRNYiWvqTL3/V6K 8dvGfLVG9gKLT+ARYyKT7oy1FVxmKARIIoF/bETi/SPryP2imFlfZN1fZMaUdkhjD8 J6QVkgThtqAoOeHrSoJd8ZACHDFbSIvuO6rsDVpq6IDz78KETXSRETvCmAPstwBa2T xDX9kf8Rmo/FwmE3xYyjLGTTUhPzzKDVLQKO2FyqFectTiQ1YDJy9LkcqYkZnbtXfZ dvUBvxdiA0mB0rFSn7idTnw/pwJBsOcrfRwBFqqSCJs2eGVc47OdsbF6QtId8+8Jwd ssRH9E5O6SPiRcuokj0CbB07HtHhRWY7wojeiU8lTfe8q0ev3W9kYGgwaumVGVMOLq gd46gAzfGQwMa7uB71UqDQOrUZcfEBYSP3gwt4iW8VJXozofs0/Zjjl5iQIaXtdJ5Q 0aXxhqEbCu+D1uiWJRJG3kNB3h2Bmj/b1vxK9Sg5qBWSl6mGL7JLtmlbWJibKljy+Z vM9SAMeH+98etQ6UuwC0Eidg= In-Reply-To: <87frrdvaku.fsf@neverwas.me> (J. P.'s message of "Fri, 09 Aug 2024 11:02:25 -0700") Autocrypt: addr=bjorn.bidar@thaodan.de; prefer-encrypt=nopreference; keydata= mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlH 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:289977 Archived-At: "J.P." writes: > Bj=C3=B6rn Bidar via "Bug reports for GNU Emacs, the Swiss army knife of = text > editors" writes: > >> I noticed that auth-source-pass doesn't match agains password file >> attributes such as those containing :user and only matches password >> files which contain a host and a user when >> auth-source-pass-extra-query-keywords is true. > > I don't use pass myself, nor have I ever, but I suppose I did add the > `auth-source-pass-extra-query-keywords' option (though mainly in a bid > to make auth-source-pass behave more like other back ends so it's usable > with ERC). Anyway, I do actually recall being somewhat aware of the > existence of the file attributes you mention. It seems I even left a > comment about the current lack of support [1]. I started using the option since my girlfriends password store is organized for many passwords as hostname.tld/user@exampl.com, when she created a password that is /example.com/user where without the option the wrong password files were used. Her mail address is user@example.com and the login server is also example.com with her name as the username (we selfhost). > Looking into this a bit, it seems the password store's web page > considers everything after the initial (password) line to be an opaque > text blob: > > The password store does not impose any particular schema or type of > organization of your data, as it is simply a flat text file, which can > contain arbitrary data. Though the most common case is storing a > single password per entry, some power users find they would like to > store more than just their password inside the password store, and > additionally store answers to secret questions, website URLs, and > other sensitive information or metadata. Since the password store does > not impose a scheme of it's own, you can choose your own organization. > There are many possibilities. > > However, I do realize that the auth-source-pass back end without the > extra-keywords option already dips into a file's contents looking for an > attributes list like the one shown on the web page. (Whether that's wise > is pretty much moot after all these years.) Anyway, for that reason, I > suppose we _should_ attempt to at least explore doing the same when the > extra-keywords option is enabled. For me, the most important thing > remains mimicking the behavior of the other built-in back ends, which at > times is admittedly unintuitive but nevertheless consistent and thus > predictable from a mechanical POV. I agree fully with the comment. Other's that use pass as source for passwords also use file contents to match or retrieve variables from. E.g. most browser plugins derive the parameter for the login or user name from either of these names. >> Steps to reproduce: >> 1. Setup pass with the following structure >> WorkingTest/example.com/foo >> FailingTest/example2.com >> FailingTest/example3.com with user: foo in the password file >> 2. (auth-source-pass-enable) >> 3. (setq auth-source-pass-extra-query-keywords t) >> 4. (auth-source-search :host "example" :user "foo") -> works >> 5. (auth-source-search :host "example2.com") -> fails >> 6. (auth-source-search :host "example3.com" :user "foo") >> >> Auth-source-pass should be able to query the password file for >> additional attributes if one of the previous attributes such as :host >> match to it. Quering the file attributes is quite important in use >> cases where it doesn't make sense to the user to have a >> host-folder/user-file structure in cases where there's only one >> password for said host. > > Currently, if you have a file in the root of your ~/.password-store > named something like "top-level-host.com", and it's contents feature a > "user: foo" attribute, both > > (auth-source-search :host "top-level-host.com") > > and > > (auth-source-search :host "top-level-host.com" :user "foo") > > return > > ((:host "top-level-host.com" :secret ...)). > > If you're saying you want to see (:user "foo") in the results as well, I > guess we can do that (see attached patch as well as [2], below). > However, this still won't work on any of your examples, which all have > intervening path components between the root directory and the .gpg > files. The reason for this restriction is explained below. > > If we do end up going with something like the attached patch, we'll need > to profile it. I can create a bunch of fake trees of varying shapes and > sizes, but I'd rather someone with real data and a sizable store assess > how much slower it is to visit (and thus decrypt) potentially every file > in the tree, which is what any attr-reading implementation must do. On > my machine, it takes roughly 0.18 seconds to decrypt a single two-line > file via `auth-source-pass--read-entry'. (This seems prohibitively > expensive to do en masse, no?) FWIW, most of this time is spent in > `epg-wait-for-status', which blocks until the subprocess exits. That is why I was arguing that we should attempt to not try decrypt the password file unless a previous attribute such as :host or :user matched before. If we could do the search in parallel or at least without blocking Emacs that would be a different story of course. >> Same it should maybe also match against :host >> if no user was provided, I don't know how other sources do this thou. > > While the reference implementation indeed succeeds with a plain :host > input (see test `auth-source-pass-extra-query-keywords--netrc-host'), I > believe the actual problem you perceive has more to do with the content > of the file paths, specifically, leading directory components. Still, > I'm inclined to agree that this would be nice to have. However, I do > seem to recall this being discussed on at least one occasion, with the > conclusion being that it's too complicated, if not impossible, to > disambiguate between a trailing "hostname/user" and "folder/hostname". > > Nevertheless, we could add an option to do it anyway based on one or > more heuristics-based strategy (resolving hosts for real is surely a no > go). For example, one such strategy could ignore a penultimate file-path > component that's not an FQDN, even if it's, say, LDH-only and resolvable > as a hostname, so long as the leaf component _is_ an FQDN. However, such > an option would have to be disabled by default to prevent existing > entries like "localhost/test.user" from being parsed as (:host > "test.user"). > What do you mean by resolving hosts for real? I think another option would be for the user to specific the hierarchy of their password store to auth-source-pass e.g. word/%host%/%user or word/(or %host word)/%user where word is any word that isn't used for matching but just for the user to organize the hierarchy. > In any case, I'm happy to review patches, but I think someone who > actually uses this back end should implement the feature. I'm not a good lisp programmar but I could give it a go with some help such as your patch as a start point. > > [1] https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/auth-source-pas= s.el?id=3D423c86cb#n300 > > [2] The following describes details of the attached patch's logic for > the inner (dolist (e entries) ...) loop of the primary matching > function `auth-source-pass--find-match-many'. Hopefully it's > somewhat sound with regard to deferring decryption for as long as > possible. > > 1. Parse the file path of each entry first and cache its results in > a plist, the "cached entry metadata," which is filed under the > entry's file-path in the `seen' hash table. If it doesn't match > the basic filename format, it must not be a passwordstore file, > so reject the entry. > 2. Check the :host field before reading the file. Unless it matches, > reject the entry. > 3. Engage in a series of probing conditional checks for a :port > field to match against a provided "port" query parameter, all > while attempting to defer decryption until absolutely necessary. > (A path-encoded :port always takes precedence over a :port in the > file.) > - If a `port' query parameter is not given for matching against, > continue to the next steps for the current entry. > - Otherwise, if a :port parsed from the file path is present and > it doesn't match, reject the entry, meaning go to the beginning > of the current loop, considering the next entry. > - If a path-derived :port is absent, ensure the cached entry > metadata contains an additional :attrs field (an alist). If the > metadata lacks an :attrs field, the file has not yet been > decrypted. Decrypt it now using `auth-source-pass-parse-entry', > then add its secret and its attrs alist to the cached metadata, > under :attrs. > - Look in the cached entry metadata's :attrs alist for a "port" > attr. If a "port" attr is indeed present and doesn't match the > port query parameter, reject the entry. > - If no such "port" attr exists and is required (meaning :port > appears in the `require' query parameter), reject the entry. > 4. Repeat step 3 for :user. The same precedence rules apply, meaning > any non-null path-derived :user field is immediately accepted, > and the file is not decrypted. > 5. If we haven't yet decrypted the file, do so now and populate the > :attrs item in the cached entry metadata. If it's already been > decrypted at some point, :attrs will present (though possibly > empty). In any case, add the items we care about if non-null > (:user, :port, and :secret) to the matched results for this entry. > However, only do so if a secret was either not required or is > present; otherwise, reject the entry.