On Sun, 17 Apr 2022 at 10:36, Greg Stein <gst...@gmail.com> wrote: > > 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.
My idea here was just to link to the sig and hash by adding the appropriate suffix to the artifact path name, and checking that it exists. e.g. look for db/jdo/3.2/jdo-3.2-source-release.tar.gz + .asc also .sha256 or .sha512 etc. The code already checks for the presence of the artifact. There aren't that many valid hash types to check; if the code cannot find the required files, it could direct users back to the project. > 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 >>
