Hi Craig, The closer.lua, its prior name closer.cgi. and all predecessors have been fine with the Foundation's consumers liking its functionality. This has supported 200+ projects (or more, depending on how you'd like to count). Changes to that system are (thus) demand-based, which we have not seen. Please provide some PRs with the changes you would like to make.
I do believe that others agree with your ideas on "automated hashes", though I really have no idea on the follow-on security details. Nor a mechanism for broad-based security chains of GPG keys and hashes for the artifacts. Figure it out, discuss on the mailing list, file some Pull-Requests, and we can move forward. Cheers, Greg InfraAdmin, ASF On Sat, Apr 16, 2022 at 6:23 PM Craig Russell <apache....@gmail.com> wrote: > I'd like to ask on behalf of the DB PMC for the infra tool closer.lua to > be enhanced a bit for use by projects. > > It will be much easier for us if we can simply link to e.g. > > https://www.apache.org/dyn/closer.lua/db/jdo/3.2/jdo-3.2-source-release.tar.gz > and have that page contain the .asc and .sha512 as well. > > Even better if closer.lua can also find the relevant KEYS file and link to > it when describing how to check the release. > > With this approach, it is easier for the project and less error-prone to > maintain the download page(s). We can include the current release as well > as archived releases on the same download page and omit the links to the > .asc and .sha512 and KEYS files. > > Please let us know how we can help. > > Regards, > Craig > > > On Apr 16, 2022, at 2:01 AM, Greg Stein <gst...@gmail.com> wrote: > > On Thu, Apr 14, 2022 at 4:43 PM sebb <seb...@gmail.com> wrote: > >> On Thu, 14 Apr 2022 at 20:52, Christopher <ctubb...@apache.org> wrote: >> > >> > Doing this would probably restrict INFRA's ability to adapt it to >> > their changing needs, as projects would become dependent on it. >> >> Projects are already dependent on the page. >> > > Correct. We *want* projects to use closer.lua. It provides a control point > to direct users to the appropriate location to download. Today, it > primarily sends them to our CDN and to an EU download location. > > Should those decisions ever change, we want projects to be using > closer.lua to effect those changes. > > >> I think it would make it easier for Infra to make changes, as they >> would be able to adjust it. >> > > Yes. > > >> > Probably best to leave the mirror-management page independent from the >> > project download pages, since they serve the needs of separate groups. >> >> I was not suggesting replacing these, for those projects that want to >> customise the pages. >> > > Today, we no longer have a mirror system. But requiring projects to use > closer.lua ensures that we can swap in that future option. > > All that said, as I recall: closer.lua provides support for .ezt pages so > that projects can provide custom download pages. Maybe there is a way to > provide the needed variables to projects' custom download page templates. > > Or, they can just keep using their pages. > > The download pages are owned by the TLPs. Infra isn't gonna interfere with > them. Should any TLPs want more features, then they can ask. We haven't > seen any requests in years from the TLPs. > > Cheers, > Greg > InfraAdmin, ASF > > > > Craig L Russell > c...@apache.org > >
