1 |
On 12/17/2014 02:32 PM, Brian Dolbec wrote: |
2 |
> On Wed, 17 Dec 2014 12:30:53 -0800 |
3 |
> Zac Medico <zmedico@g.o> wrote: |
4 |
> |
5 |
>> Hi, |
6 |
>> |
7 |
>> For server deployments, it's common for administrators to want to use |
8 |
>> glsa-check for security vulnerabilities, without necessarily wanting |
9 |
>> to to do a full sync [1]. |
10 |
>> |
11 |
>> So, I propose that we add an 'emerge --sync-glsa' action and a |
12 |
>> corresponding 'emaint sync-glsa' command that will only sync the |
13 |
>> relevant metadata/glsa subdirectory of the relevant repository(s). |
14 |
>> Please respond if you agree or disagree with this proposal. |
15 |
>> |
16 |
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=89641 |
17 |
> |
18 |
> I agree in principal, but you didn't say enough about your idea to be |
19 |
> able to say yes/no to it yet. |
20 |
|
21 |
Yeah, I need to explain the implementation ideas that were floating |
22 |
around in my head when I made the proposal. |
23 |
|
24 |
> I've read the bug comments. |
25 |
> |
26 |
> So, what you are saying for the above is set a very restrictive rsync |
27 |
> to just sync the glsa directory? |
28 |
> |
29 |
> So, with the new pluging-sync sytem in place, how do you propose we do |
30 |
> this? |
31 |
> |
32 |
> 1) Make a new emaint sync option which does the restriction and |
33 |
> appropriate sync module calls? |
34 |
> emaint sync --glsa & emerge --sync-glsa |
35 |
> |
36 |
> 2) emaint sync-glsa sounds like a modified copy of the sync module. |
37 |
> To me this is a poor idea. It would needlessly duplicate code. |
38 |
|
39 |
I was thinking that we could tag the repos containing glsas using an |
40 |
attribute in repos.conf, and teach the existing rsync module how to sync |
41 |
the glsas alone. |
42 |
|
43 |
> But what about the different sync types. How do we handle this in a |
44 |
> git repo instead of an rsync one? |
45 |
|
46 |
I was thinking that we would only need to implement this for the rsync |
47 |
repo, since that's the only one that includes the glsas. If there's some |
48 |
reason to implement it for other sync types in the future, then we can |
49 |
do it when the need arises. |
50 |
|
51 |
> |
52 |
> 3) if it is a separate repo, then the current emaint sync |
53 |
> module does not need __ANY__ modifications. |
54 |
> |
55 |
> emaint sync -r glsa <== would sync the repo named glsa no |
56 |
> matter what type of sync method is used. rsync, git, svn, |
57 |
> cvs,... |
58 |
> |
59 |
> Another advantage to a separate repo, for your use case that |
60 |
> they don't want the main repo to be synced, the new sync system |
61 |
> adds an "auto-sync" variable. "emerge --sync" will only sync |
62 |
> repos marked with it set to yes. So, if all they want is the |
63 |
> glsa's synced automatically, set only i'ts auto-sync to yes. |
64 |
> All other repos will have to be synced manually via the "emaint |
65 |
> sync --repo foo" command which does not look at the auto-sync |
66 |
> variable. |
67 |
|
68 |
Well, it sounds like you're introducing a new "repo" type that's |
69 |
different from a package repository. That's not really necessary if we |
70 |
take the approach that I've describe above. |
71 |
|
72 |
> Bottom line of this comes down to getting infra to create a standalone |
73 |
> repo for the glsa's. The current rsync tree could merge the gentoo and |
74 |
> glsa repos for backwards compatibility. For your use case, they set the |
75 |
> gentoo repo's rsync restriction to exclude the glsa's. And have the |
76 |
> separate glsa repo downloaded as it's own repository. With the gentoo |
77 |
> tree moving to git, then the git tree would not include the glsa's, so |
78 |
> the user would need to install the glsa tree as well. |
79 |
|
80 |
Note that we can even re-use the existing rsync tree if we take the |
81 |
"separate repo" approach, and simply configure the "separate repo" to |
82 |
sync from rsync://rsync.gentoo.org/gentoo-portage/metadata/glsa instead |
83 |
of rsync://rsync.gentoo.org/gentoo-portage. |
84 |
|
85 |
> Only code changes I see to portage, pkgcore (I know nothing about |
86 |
> paludis) are to look for the glsa's in the 2 possible locations. The |
87 |
> standalone glsa repo, failing that, backup to the gentoo tree. |
88 |
|
89 |
Well, is there anything wrong with the tagging the existing repo in |
90 |
repos.conf as I've described above? |
91 |
-- |
92 |
Thanks, |
93 |
Zac |