Add ollama auth and custom client kwargs

[TheRisenPhoenix]

This PR adds the possibility to pass kwargs to the Ollama client. This enables support for an enhanced ollama configuration, for example for instances that require an authorization header or that are self hosted (which is likely with ollama), thus also likely having a self-signed certificate that httpx will reject (and which can be circumvented by passing verify=False).

Personally, I'd benefit hugely from this rather small changes, finally being able to correctly configure the client for my instance without the need of some hacky circumventions. :)

Verification

This is an example for connecting to a fictional (!) ollama server that is self-hosted with self-signed certificates and requires authentication.

• Supporting configuration such as generator configuration file

{
    "ollama": {
        "OllamaGeneratorChat": {
            "host": "https://my-self-hosted-server.com/ollama",
            "client_kwargs": {
                "verify": false,
                "headers": {
                    "Authorization": "Bearer sk-123456789abc"
                }
            }
        }
    }
}

• garak -t ollama -n gemma3:latest --probes test.Blank
• Run the tests and ensure they pass python -m pytest tests/ (5673 passed, 105 skipped, 2 warnings)
• Verify the thing does what it should
• Verify the thing does not do what it should not
• Document the thing and how it works (Example)

[Copilot]

Pull request overview

Adds a new configuration knob to Ollama generators so users can pass additional keyword arguments through to the underlying ollama.Client constructor, enabling custom HTTP/TLS/auth configuration for self-hosted or secured Ollama endpoints.

Changes:

• Add client_kwargs to OllamaGenerator.DEFAULT_PARAMS.
• Forward client_kwargs into the ollama.Client(...) instantiation.

Suppressed comments (2)

garak/generators/ollama.py:44

• Passing client_kwargs via **(...) after timeout=self.timeout will raise TypeError: got multiple values for keyword argument 'timeout' if the user also supplies timeout in client_kwargs. Build a single kwargs dict and pass it once so client_kwargs can safely override the default timeout.

        self.client = self.ollama.Client(
            self.host, timeout=self.timeout, **(self.client_kwargs or {})
        )  # Instantiates the client with the timeout

garak/generators/ollama.py:43

• New behaviour is introduced by forwarding client_kwargs into the underlying client, but the existing mocked Ollama generator tests don't exercise this. Add a unit test (e.g. with respx) that sets client_kwargs (headers/verify/timeout override) and asserts the resulting request uses the expected settings.

        self.client = self.ollama.Client(
            self.host, timeout=self.timeout, **(self.client_kwargs or {})

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jmartin-tech]

This revision does provide what is describe, however I suspect the goal it seems to be targeting, that of enabling authorization tokens and ssl validation suppression in the example, are things that would benefit from first class support.

{
    "ollama": {
        "OllamaGeneratorChat": {
            "host": "https://my-self-hosted-server.com/ollama",
            "api_key": "sk-123456789abc"
            "verify_ssl": false
        }
    }
}

Note as with other generators the api_key would be possible to directly supply or have supplied via the default ENV_VAR or a custom key_env_var specified in the generators configuration. Allowing for more portable and more secure configuration patterns.

The suggestions guide towards how I think this can be accomplished and aligned to the patterns in other generators.

If extended arguments need to be possible to configure on the client, I think we can that could be added via a similar pattern to the original offer here though with some extended precedence controls similar to how OpenAICompatible enables extra_params.

Note this PR triggered team discussion that should also lead to better documentation on what should be considered for inclusion as first class supported attributes for generators and how configuration precedence should be handled when resolving competing first class parameter attributes and free form parameters like the one suggested in this PR.

[TheRisenPhoenix]

Thank you for your review @jmartin-tech !
I agree that first class support for these common parameters is even better, and I changed it as you suggested.
I prefer, however, to also enable extra_params and took a look at OpenAICompatible as you suggested, and implemented it similar to as it is done there.
I also made sure that provided headers still play along well with authentication headers, if an api key is provided.

A new exemplary config file could look like this:

{
    "ollama": {
        "OllamaGeneratorChat": {
            "host": "https://my-self-hosted-server.com/ollama",
            "verify_ssl": false,
            "extra_params": {
                "headers": {
                    "User-Agent": "Mozilla/5.0"
                }
            }
        }
    }
}

[jmartin-tech]

This rework looks great, and the support for extra_params is a great add.

I think a unit test or so would help document this and also increase confidence this is working as desired.

[jmartin-tech]

One more note looking at the latest config example. User-Agent is actually a global run config option that I suspect the Ollama client is already getting a custom value set by garak for as the tool sets this for use by the requests lib.

[TheRisenPhoenix]

One more note looking at the latest config example. User-Agent is actually a global run config option that I suspect the Ollama client is already getting a custom value set by garak for as the tool sets this for use by the requests lib.

That's totally possible, I was just looking for a quick and easy example for a header to demonstrate the header union in practice :D

[jmartin-tech]

Minor testing feedback and this will be ready to land.