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