Hi Tison, Would it be possible to provide us with links to documentation about how you deploy your binary artifacts and how they can be revoked if a vote fails?
I think this is useful for IPMC members when they are reviewing your release candidates. It's nice to review the binaries as well as the source artifacts, even if the source artifacts are the main point of the vote. When staging RCs for review, I tend to use * dist.apache.org (this is where the source artifacts go anyway) * repository.apache.org (jars) Files on dist.apache.org can be deleted when votes fail. With repository.apache.org, the release is a 2 phase process. You first push to 'staging' and then you can use its Nexus UI to drop or release the staged artifacts after the vote. OpenDAL is mainly in Rust but you also have a large number of language bindings (see libraries list [1]), existing and planned. So presumably, you are using a large number of different packaging tools for your binary releases. Many of us in the IPMC would not be familiar with all these packaging tools. You may already have documentation and if so, could you share a link? If there is no shareable documentation, would you be able to tell us which Crate Registry do you use for your RC Rust binaries? Do we have a custom registry that allows us to remove the binaries for releases that fail? Any information would be appreciated. Regards, PJ [1] https://github.com/apache/incubator-opendal On Tue, 4 Jul 2023 at 05:29, Greg Stein <gst...@gmail.com> wrote: > > Tison: STOP cross-posting between private and public lists. You have been > advised to stop doing so once, and this is now TWICE. No more. > > Regards, > Greg Stein > Infrastructure Administrator, ASF > > > On Mon, Jul 3, 2023 at 6:01 AM tison <wander4...@gmail.com> wrote: > > > Hi Daniel, > > > > Thanks for your information! That can be an alternative for the signing > > key. > > > > Right now the blocker I met is 403 from the Nexus server which I suspect is > > the lack of permissions from the Nexus credentials. Could you confirm or > > correct it? > > > > Best, > > tison. > > > > > > tison <wander4...@gmail.com> 于2023年7月3日周一 18:58写道： > > > > > Hi PJ, > > > > > > Thanks for sharing your thoughts! > > > > > > For signing key, it's a resolved topic from my perspective. I use - > > > > > > 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1] > > > 2. Load the key from our 1password service, while since it's a specific > > > key, I feel comfortable to pass it to INFRA member and configure as a > > > secret alternatively. > > > > > > Best, > > > tison. > > > > > > [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS > > > > > > > > > PJ Fanning <fannin...@apache.org> 于2023年7月3日周一 18:52写道： > > > > > >> Adding the Incubator general list. > > >> > > >> My view would be that non-snapshot binary artifacts should be signed > > >> with a personal signing key - ideally the signing key that was used to > > >> release the related source release. Unfortunately, this would mean > > >> adding a user's signing key to the Apache GitHub account as a secret > > >> so that the automated GitHub Action job could access it. I don't see > > >> how we could allow personal signing keys to be added like this. > > >> > > >> On Mon, 3 Jul 2023 at 10:18, tison <wander4...@gmail.com> wrote: > > >> > > > >> > cc security > > >> > > > >> > Missed in the first place. > > >> > > > >> > Best, > > >> > tison. > > >> > > > >> > > > >> > tison <wander4...@gmail.com> 于2023年6月29日周四 22:21写道： > > >> >> > > >> >> Hi security team members, > > >> >> > > >> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding. > > >> >> > > >> >> I already verify that GitHub Actions work well for automatically > > >> deploying OpenDAL Java binding[2]. > > >> >> > > >> >> When integrating it with upstream (apache/incuabtor-opendal), I met a > > >> problem that deploying Maven projects requires NEXUS credentials. For my > > >> personal repo, I can config my Apache ID and password as secrets. For > > >> apache repos, it requires handing over the credentials to INFRA team > > >> member. Even I can trust the member, it's a bit less than awesome. > > >> >> > > >> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and > > >> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only. > > >> INFRA member suggested me to consult security team for approval for such > > >> automatic deployment and they would help to grant related permissions if > > >> approved. > > >> >> > > >> >> Please help review the request to support ASF projects deploying > > Maven > > >> project via GitHub Actions. > > >> >> > > >> >> Best, > > >> >> tison. > > >> >> > > >> >> [1] http://github.com/apache/incubator-opendal > > >> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752 > > >> >> [3] > > >> > > https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192 > > >> >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > >> For additional commands, e-mail: general-h...@incubator.apache.org > > >> > > >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
