Feature request description

Our goal is to use a quadlet to pull a container image on a host with an IPv6-only network interface. The host has no direct internet access and must use an IPv6-accessible HTTP proxy. We need to configure this proxy for the podman pull command during service startup.

Steps to Reproduce

1. Set up a system with an IPv6-only network interface and no default IPv4 gateway.
2. Ensure there is an HTTP proxy available that is reachable via IPv6.
3. Create a quadlet file, for example, /etc/containers/systemd/my-service.container, with AutoUpdate=registry.
4. Configure the proxy. The only working solution we found was a combination of a [Service] section and a PodmanArgs option:

   [Container]
   # ... other options ...
   PodmanArgs=--http-proxy=false
   
   [Service]
   Environment=HTTP_PROXY=... HTTPS_PROXY=...

Actual Behavior

The only method that successfully proxies the podman pull operation on this network configuration is to set the HTTP_PROXY and HTTPS_PROXY environment variables in the [Service] section and then explicitly disable them from being passed to the container using PodmanArgs=--http-proxy=false.

Suggest potential solution

Expected Behavior

We would expect a more direct and declarative option within the [Container] section of the quadlet file, such as HttpProxy=... or PullEnvironment, that would configure the proxy for the podman pull operation. This would eliminate the need for a separate [Service] section and the less-obvious PodmanArgs workaround.

Why a Dedicated Option Is Needed

A dedicated HttpProxy option is needed to simplify configuration and improve readability. Relying on the [Service] section and the --http-proxy=false flag is unintuitive and requires specific knowledge of how systemd passes environment variables to Podman. This workaround complicates a common network scenario and makes the container's purpose less clear. A single, declarative option would streamline the quadlet definition, making it more robust and user-friendly for handling proxy-related tasks.

Have you considered any alternatives?

The only alternative I have is my current solution for the issue.

Additional context

This report assumes that the container registry that podman downloads the image from is accessible only through the internet (not in the internal network).