Björn Bidar writes: > "J.P." writes: > >> 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. Hm, actually, I was not initially thinking of including all the attributes, only :user and :port. But it seems I'd forgotten that the netrc reference implementation does indeed include arbitrary key/value pairs in the results from a successful match: # ~/.authinfo machine example.org login me password 123 foo bar M-: (auth-source-search :host "example.org") => (... :foo "bar") I've updated my previous patch to do this. >> 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. With what I'm proposing, we would actually decrypt to inspect the parsed attrs if :port or :user isn't found in the filename and a port or user query parameter is given (or :port or :user appears in a :require parameter). This behavior is currently gated by a new variable called `auth-source-pass-check-attrs-with-extra-query-keywords', but it's t by default. Perhaps it's better to have it be nil? If we do that, then, by default, :port and :user attributes won't be considered, but they will still be included in successful matches along with all other attributes. >>> 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 just meant it'd be unrealistic to query the system resolver via `network-lookup-address-info' or similar whenever we need to disambiguate. > 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. That could work, although it seems rather complex with pattern substitutions and expressions (?). Perhaps it could be precomputed somehow into a regexp before every query. Another idea would be to just have the option be an integer indicating the number of leading path components to mask off before matching. Given a tree like ~/.password-store/ - foo/ - example.com - irc.bar.org/ - example.net/ - me - baz/ - myvps/ - my.user.name if the option (which is 0 by default) were set to 1, then possible results might be (:host "example.com" :user "some-attr") (:host "example.net" :user "me") (:host "myvps" :user "my.user.name") Although this won't work if a user wants different mask depths for different sub-directories. >> 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. I should be able to handle the attribute feature, unless you want to improve upon it. It's mainly the disambiguation feature that I'd want an actual pass user, like yourself, to implement or at least help design. (Although feel free to offer patches of any nature, including based on anything I've proposed.)