On Sun, Sep 07, 2014 at 09:03:00PM -0400, 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). > > 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. >
What you're saying makes perfect sense at the developer->infra side, but as you've conceded, not so much at the infra->mirror side. Clearly instead of every user downloading a git clone, it's better to pin to that commit and have the push script hook with infra to automate a tarball, since the dev->infra channel is secure, and the SHA1 is current at that point. That would enable you to submit a pinned ebuild with the relevant keywords, users to download standard tarballs and verify if needed (since the commit id is in the ebuild, and that has a strong manifest); the saving in bandwidth is something sponsors might go for. I'm sure many users would be happy to contribute in various fashions, too; though I'd ask patrick to consult and perhaps provide backend if infra is stretched. He runs hosts for quite a lot of gentoo people already, as well as git and trac machines, and the tinderbox, on gentooexperimental.org. Regards steveL. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
