1 |
On Wed, Jan 24, 2018 at 2:58 PM, Michał Górny <mgorny@g.o> wrote: |
2 |
|
3 |
> W dniu śro, 24.01.2018 o godzinie 12∶54 -0500, użytkownik Alec Warner |
4 |
> napisał: |
5 |
> > On Wed, Jan 24, 2018 at 3:56 AM, Michał Górny <mgorny@g.o> wrote: |
6 |
> > |
7 |
> > > Hi, everyone. |
8 |
> > > |
9 |
> > > Since the initial review of my patch lost focus, and lacked sufficient |
10 |
> > > context, here's the plan that I'd like to follow in order to initially |
11 |
> > > integrate gemato with portage and give our users secure checkouts by |
12 |
> > > default. |
13 |
> > > |
14 |
> > > 1. Add postsync hook to Portage git. Eventually, it will be replaced by |
15 |
> > > direct Portage support. |
16 |
> > > |
17 |
> > > 2. Add IUSE=+rsync-verify to portage-9999 that controls installing the |
18 |
> > > hook. This will give users the ability to easily disable it without |
19 |
> jumping |
20 |
> > > through cross package hoops. |
21 |
> > > |
22 |
> > |
23 |
> > I think it makes sense to avoid installing the hook through this means |
24 |
> > (e.g. I don't want it, so I set USE=-rsync-verify) |
25 |
> > |
26 |
> > I think its a bit trickier to control the hook's behavior. For instance: |
27 |
> > |
28 |
> > 1) I install portage[rsync-verify]. This installs the hook. |
29 |
> > 2) I end up not liking the hook, I install portage[-rsync-verify] |
30 |
> > 3) Does the hook get config-protected here? |
31 |
> |
32 |
> Keeping config-protected files applies only if the file were modified. |
33 |
> In this case it just gets unmerged. I've just verified that. |
34 |
> |
35 |
> > > 3. Submit a news item for review that will explain how to initially |
36 |
> verify |
37 |
> > > the keys on existing installations. |
38 |
> > > |
39 |
> > > The news item would be published when the hook hits a release. |
40 |
> > > |
41 |
> > > What do you think? If you agree, then I'll start writing the news item. |
42 |
> > > |
43 |
> > |
44 |
> > The other part of the user story I don't understand is what actions |
45 |
> should |
46 |
> > users take when verification legit fails? |
47 |
> > |
48 |
> > 1) file a bug? |
49 |
> > 2) re-sync their tree? |
50 |
> > 3) something else? |
51 |
> |
52 |
> I'd say one re-sync would be reasonable in case it could have been some |
53 |
> rsync glitch. Beyond that, it would definitely be worth reporting... |
54 |
> except the user will probably hit another mirror. |
55 |
> |
56 |
|
57 |
This sgtm. |
58 |
|
59 |
If the number of reports is high we can build more complex reporting |
60 |
infrastructure (e.g. to locate bad mirrors.) |
61 |
|
62 |
-A |
63 |
|
64 |
|
65 |
> |
66 |
> -- |
67 |
> Best regards, |
68 |
> Michał Górny |
69 |
> |
70 |
> |
71 |
> |