On Mar 21, 2022, at 9:20 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> Ports that fetch their sources from a revision control system do not enjoy 
> the protection of checksums. Although ports that fetch source from a revision 
> control system specify which tag or commit hash to fetch, it is conceivable 
> that a developer with sufficient access to that repository could delete an 
> old tag and replace it with a new tag of the same name that contains 
> different software. This is one of the reasons why we recommend ports fetch 
> using distfiles, and the vast majority do. We might consider recommending 
> that ports that fetch directly from a git repository (fetch.type git) never 
> use a tag, and always use the commit hash corresponding to that tag, since 
> replacing the contents of the repository while keeping the same sha1 hash is, 
> as far as I know, still impossible in the general case. (Yes, it is possible 
> to engineer a sha1 collision, but only if you can carefully control both the 
> old and new files. Generating a sha1 collision against some existing old file 
> is a very different matter.)

I haven't reviewed the current literature but one thing is certain - attacks 
only get better. We should strongly discourage any use of revision control as 
the source.

We could shorten the window where a person could get sources that don't match 
what the maintainer expected with a little infrastructure magic. Roughly in 
order of presumed level of effort:

- provide a place for maintainers to manually upload distfiles that they can 
generate from a source checkout
- provide some port command for maintainers to upload distfiles (as a 
convenience for the above upload process)
- have a process that automatically generates distfiles from the checked out 
source and puts it on our mirrors (builder could probably do this since it's 
already going to check out the source), then have base look for the distfile on 
our mirrors first (even if the portfile specifies to check out from a revision 
control system)

-- 
Daniel J. Luke

Reply via email to