gpg-connect-agent: might be able to execute its arguments, how to ignore

[clkamp]

I have a script, that calls gpg-connect-agent that I want to package for nix using resholve. As far as I know, the input used here is not executed. Is there a way to tell resholve, that its okay to just resolve the reference to gpg-connect-agent?

[abathur]

There is.

The ideal outcome of these is to improve resholve and/or binlore to fix it for everyone, but when you need a short-term workaround, you can add execer lore as in:
https://github.com/NixOS/nixpkgs/blob/d5f325f761e6b07e199e7f1f2906397c5da16947/pkgs/development/misc/resholve/README.md?plain=1#L218-L224

Let me know if that isn't clear and I can dig up a full example.

I don't expect you to go down the ideal path here, but I still need to ~document it--so I'll follow this up with another comment in the hope that I can get your thoughts on whether it makes sense.

[clkamp]

Thank you very much.

As a workaround, your tip works nicely and I will have a look on your comment how to do it the right way :)

[abathur]

I'll have to iterate towards "how to"; it's a little more fundamental for now. I'll definitely need help scaling it out, but I'm leery of investing a lot of potential dev time writing guides sufficient for others to do it from before they're obviously needed.

To start, I'm curious if this decision chart makes sense:

flowchart TD
    Z[binlore searches executables for use of known exec calls] --> A[resholve complains when  it finds a potential execer] --> B{Is any package executable common in scripts?}
    B --->|Yes| C[we should address in binlore or resholve]
    B -->|No| D[callers will need to supply lore for less common packages]
    C --> E{Do package doc/source indicate user-supplied executable args?}
    E -->|No| F[binlore: override package's lore to mark safe executables as 'cannot']
    E --->|Yes| G[resholve: add command-specific syntax rules to identify executable args]

Loading

[clkamp]

I'm not sure what you mean with "long-tail lore" otherwise the flow-chart is totally understandable

[abathur]

good catch :)

changed from "long-tail lore" to "lore for less-common packages"

[clkamp]

Here are my thoughts on gpg-connect-agent following your flowchart:

1. gpg-connect-agent could be used in at least some scripts, so it might be an candidate to handle in binlore/resholve
2. It has some user-supplied executable arguments, so it should be handled in resholve

Source: https://www.gnupg.org/documentation/manuals/gnupg/Invoking-gpg_002dconnect_002dagent.html#Invoking-gpg_002dconnect_002dagent

Options that I found, that execute user-supplied arguments:

-E
--exec

    Take the rest of the command line as a program and it’s arguments and execute it as an Assuan server.

--agent-program file

    Specify the agent program to be started if none is running. The default value is determined by running gpgconf with the option --list-dirs. Note that the pipe symbol (|) is used for a regression test suite hack and may thus not be used in the file name.

--dirmngr-program file

    Specify the directory manager (keyserver client) program to be started if none is running. This has only an effect if used together with the option --dirmngr.
--keyboxd-program file

    Specify the keybox daemon program to be started if none is running. This has only an effect if used together with the option --keyboxd.