On 2019/01/02 11:59, Charles A Daniels wrote: > > The alternative is to mirror stable distfiles. > > Mirror them where? Someone will have to pony up the developer time and > infrastructure (hardware, disk space, bandwidth) to make that happen at > any kind of scale.
Wherever is convenient for that person. Could even be hosted on github ;-) That hasn't proven itself to be a problem thus far, many software projects do have a proper release generation process. If it becomes more widely needed then maybe it would be worth having some infrastructure to generate and host tars from git repos centrally ourselves. (I think that needs doing at port creation/update time, the fetches done on build machines are deliberately very simple - the amount of code with network access privileges on those machines is very limited). That could also take care of the things like submodules which these simple cgi frontends to git-archive don't handle. > > Those are simply to make the URLs and directory names easier to work with > > and don't do anything to increase distfile stability. > > I am aware. The point I was getting at, which in retrospect I didn't > explain very clearly, is that this appears something that the GitLab > folks care about to some extent. Raising the issue with them might be > worthwhile. Given that these can be needed for *any* commit not even just tags, generating on the fly is really the only sane way from their point of view. > > Github at least has uploadable release assets which allow projects to > > provide stable distfiles without looking for alternative hosting. > > (And guess what, that doesn't use the GH_* support because it's just > > a simple download and most upstreams have sensible directory names > > etc). The best you can do with Gitlab is the dirty hack of committing > > distfiles themselves to a repo. > > I believe the public GitLab instance also has a GitHub-Pages work- > alike. In principle one could have CI script to upload release > artifacts there. That's a pretty gross solution though. > > > On-the-fly tarball generation is simply not compatible with checking > > distfile hashes to ensure that the downloaded files are not corrupted > > or backdoored. > > Admittedly I'm not deeply familiar with the tar binary format, but I > don't see why GitHub (et al.) couldn't make on-the-fly generation > produce tarballs with consistent hashes if they wanted to. Taking the > same set of files and generating a tar with them multiple times aught > to produce the same binary as a result no? This doesn't prevent the > upstreams from misbehaving by rebasing over an existing tag, but then > again they could also delete and re-upload an artifact with the same > name - in either case that *should* cause a checksum failure. It's not (usually) a "changes every time" thing (as long as creation timestamps are set to something that doesn't move around - though that has been a problem in the past). But changes to git, the tar program, the compression program, can all result in a different produced file. And of course changes to give nicer directory names as above would do the same! These can either be changed over time, or different versions can be present at the same time on different nodes around the world - in which case the files would be fetchable for some people but not others (we've seen this with github files).
