[gentoo-dev] Re: Does the scm ebuild masking policy make sense for git?

[Steven J. Long]

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 ;-)