ndimiduk commented on PR #4716: URL: https://github.com/apache/hbase/pull/4716#issuecomment-1224209423
> I also changed the script locally to use `agent-socket` instead of `agent-extra-socket` but probably this is just a different usage. > > I own the build machine so I can put the private key on the machine. But IIRC, what @busbey suggested in the past, is to use agent forwarding so you do not need to put your private key on the build machine. See here > > https://wiki.gnupg.org/AgentForwarding > > So maybe we could make this configurable? By default we will use local key, but with a special command line argument we could still use the extra socket. > > Thanks. When local machine (host) runs Linux, I believe that the script mounts the local `~/.gnupg` directly into the container, so no agent forwarding is used. In this case, I think the default behavior is for `gpg` to communicate with `gpg-agent` over `agent-socket`. When local machine (host) in MacOS (and presumably also when running Windows), the docker daemon is running inside of a VM (guest), so we have to do this agent-forwarding thing. The suggestion is to use the restricted socket, `agent-extra-socket`, when forwarding. However, we're forwarding to a VM running locally, so I think it's no real security concern. When local machine is not the build machine, like a build machine (linux) running in public cloud, you should probably just forward the `agent-extra-socket` to the remote host. The build host mounts that socket directly into the docker container, and so it probably fails in the same way as the MacOS version. So in all cases there's a gpg-agent involved. I suppose yes, we could add a configuration option, something like `--gnupg-proveledged-socket`, defaults to `false. When `false, it would forward the `agent-extra-socket`. When `true`, it would forward `agent-socket`. Our "dumb" instruction are, try the default first, and if that fails due to permission issue, use `--gnupg-proveledged-socket=true`. WDYT? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org