>>>>> On Sun, 7 Sep 2014, Rich Freeman wrote: > Right now the general policy is that we don't allow unmasked (hard or > via keywords) ebuilds in the tree if they use an scm to fetch their > sources. There are a bunch of reasons for this, and for the most part > they make sense.
> I was wondering if this policy still made sense in the case of scm > ebuilds that pull a particular git commit. While portage can't check > the Manifest, the fact is that git will in this case, and since we're > pointed at a content-hashed commit we can ensure that the package > never changes. We of course can't mirror it with the current setup > (there is no real reason we couldn't mirror git, but this is a > different problem). Our Manifest files contain strong hashes though, while the git commit IDs are SHA1, which is marginal from a security point of view. > Tying ebuilds to a git commit has pros and cons, but I'm hard-pressed > to think of any actual QA issues. That is, something that would make > our tree inconsistent, or create a security vulnerability. > Am I just not thinking of something? It would probably be most useful > for packages that track a backport branch or something along those > lines - where upstream does not regularly update their tarballs so > we're constant creating patchsets. In this case all we'd have to do > is bump the commit ID in the ebuild. Please let's not change the policy for git sources. Apart from the above mentioned issue, also availability of an upstream git server can never be as good as our mirror system. What is the problem with making snapshot of some git commit and placing it on mirrors? Ulrich
pgpi___3Y6_Ej.pgp
Description: PGP signature
