[GitHub] [hbase] ndimiduk commented on pull request #4716: HBASE-27312 Update create-release to work with maven-gpg-plugin-3.0.1 and gnupg >= 2.1.x
ndimiduk commented on PR #4716: URL: https://github.com/apache/hbase/pull/4716#issuecomment-1307339256 > I'm a bit confusing, here you said we must use the 'extra' socket but what you have done in this PR is to remove the usage of 'exrta' socket? Sorry I can not follow. You're absolutely correct. I've swapped the meaning of "standard" and "extra" in my mind. Sorry to add confusion, I've been away from this issue for a while. -- 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
[GitHub] [hbase] ndimiduk commented on pull request #4716: HBASE-27312 Update create-release to work with maven-gpg-plugin-3.0.1 and gnupg >= 2.1.x
ndimiduk commented on PR #4716: URL: https://github.com/apache/hbase/pull/4716#issuecomment-1307327959 @Apache9 > What do you mean by 'standard socket'? The best summary description that I've found of the various gpg-agent sockets is https://unix.stackexchange.com/a/605639. It refers to entries in the Arch Linux wiki, so it may not be authoritative. > I'm not an expert here, for me, I always need to change the extra-socket to socket when using the scripts locally on an ubuntu 22.04 machine... Yes, this is my point -- since we upgraded to this combination of gpg and maven-gpg-plugin, builds require use of the `extra` socket. This is why I think that we should merge this patch as is, without adding extract flags to enable the user to select which socket is used. -- 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
[GitHub] [hbase] ndimiduk commented on pull request #4716: HBASE-27312 Update create-release to work with maven-gpg-plugin-3.0.1 and gnupg >= 2.1.x
ndimiduk commented on PR #4716: URL: https://github.com/apache/hbase/pull/4716#issuecomment-1307294865 I filed and linked to https://issues.apache.org/jira/browse/MGPG-92. -- 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
[GitHub] [hbase] ndimiduk commented on pull request #4716: HBASE-27312 Update create-release to work with maven-gpg-plugin-3.0.1 and gnupg >= 2.1.x
ndimiduk commented on PR #4716: URL: https://github.com/apache/hbase/pull/4716#issuecomment-1307287612 @saintstack @Apache9 what do you think? -- 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
[GitHub] [hbase] ndimiduk commented on pull request #4716: HBASE-27312 Update create-release to work with maven-gpg-plugin-3.0.1 and gnupg >= 2.1.x
ndimiduk commented on PR #4716: URL: https://github.com/apache/hbase/pull/4716#issuecomment-1307286566 Given that with a modern GnuPG and maven-gpg-plugin, this change is necessary for signing/releasing to work, I think that we should merge this patch as is. I don't see a use-case where someone would be able to use the standard socket. We should, perhaps, warn/error in the presence of an old GnuPG. I also checked the released issues in maven-gpg-plugin 3.1.0 (the latest release), and I see no mention of socket use or `--pinentry-mode error`. I think that we should upgrade to the latest version of the maven-gpg-plugin, but that can be a separate issue. -- 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
[GitHub] [hbase] ndimiduk commented on pull request #4716: HBASE-27312 Update create-release to work with maven-gpg-plugin-3.0.1 and gnupg >= 2.1.x
ndimiduk commented on PR #4716: URL: https://github.com/apache/hbase/pull/4716#issuecomment-1285277185 I've not attempted release candidates anytime recently, so the status here is not changed. There's a couple reviewer questions about the wisdom of exposing the socket with elevated privileges. The changes here that allowed me to proceed may not make sense for other environments. For example, if someone is building an RC on a 3PC, they may not want the full privileged socket exposed to the remote environment. However, I don't know if any of our release managers are building on "untrusted" hardware. -- 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
[GitHub] [hbase] ndimiduk commented on pull request #4716: HBASE-27312 Update create-release to work with maven-gpg-plugin-3.0.1 and gnupg >= 2.1.x
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
