1 |
On 07/08/2018 02:50 PM, Aaron W. Swenson wrote: |
2 |
> On July 8, 2018 5:38:48 PM EDT, Zac Medico <zmedico@g.o> wrote: |
3 |
> |
4 |
> On 07/08/2018 02:18 PM, Michał Górny wrote: |
5 |
> |
6 |
> W dniu nie, 08.07.2018 o godzinie 14∶11 -0700, użytkownik Zac Medico |
7 |
> napisał: |
8 |
> |
9 |
> On 07/08/2018 01:18 PM, Zac Medico wrote: |
10 |
> |
11 |
> On 07/08/2018 01:08 PM, Michał Górny wrote: |
12 |
> |
13 |
> W dniu nie, 08.07.2018 o godzinie 11∶57 -0700, |
14 |
> użytkownik Zac Medico |
15 |
> napisał: |
16 |
> |
17 |
> On 07/08/2018 11:42 AM, Michał Górny wrote: |
18 |
> |
19 |
> W dniu nie, 08.07.2018 o godzinie 11∶04 |
20 |
> -0700, użytkownik Zac Medico |
21 |
> napisał: |
22 |
> |
23 |
> On 07/08/2018 06:56 AM, Michał Górny wrote: |
24 |
> |
25 |
> W dniu nie, 08.07.2018 o godzinie |
26 |
> 15∶02 +0200, użytkownik Kristian |
27 |
> Fiskerstrand napisał: |
28 |
> |
29 |
> On 07/08/2018 08:53 AM, Michał |
30 |
> Górny wrote: |
31 |
> |
32 |
> Is safe git syncing |
33 |
> implemented already? If not, |
34 |
> maybe finish it first and |
35 |
> cover both with a single |
36 |
> news item. Git is going to |
37 |
> be more efficient here, so |
38 |
> people may want to learn |
39 |
> they have an alternative. |
40 |
> |
41 |
> |
42 |
> Why complicate things, and |
43 |
> increase wait for something that |
44 |
> benefits |
45 |
> most users, just to give |
46 |
> alternatives to a few using |
47 |
> non-default sync |
48 |
> mechanism. Securing git |
49 |
> distribution is a whole |
50 |
> different ballpark. |
51 |
> |
52 |
> |
53 |
> |
54 |
> Let me rephrase. Let's say I'm using |
55 |
> rsync. This new feature is |
56 |
> something positive but it breaks my |
57 |
> use case (for one of the listed |
58 |
> reasons -- overlayfs, inode use, |
59 |
> small fs cache). After reading this |
60 |
> news item, I learn that my only |
61 |
> option is to disable the new feature. |
62 |
> |
63 |
> Now, I would appreciate being told |
64 |
> that there's an alternate sync method |
65 |
> that handles secure updates without |
66 |
> having all those drawbacks. |
67 |
> |
68 |
> |
69 |
> The thing is, the normal git tree |
70 |
> doesn't even provide pre-generated |
71 |
> metadata, and I see then gentoo-mirror |
72 |
> repo that provides metadata does |
73 |
> not have commits signed with an release key: |
74 |
> |
75 |
> https://github.com/gentoo-mirror/gentoo/commits/stable |
76 |
> |
77 |
> So I'm really not comfortable |
78 |
> recommending git to anyone at this point. |
79 |
> |
80 |
> |
81 |
> Wrong twice. |
82 |
> |
83 |
> Firstly, the canonical URL is: |
84 |
> |
85 |
> https://anongit.gentoo.org/git/repo/sync/gentoo.git |
86 |
> (https://gitweb.gentoo.org/repo/sync/gentoo.git) |
87 |
> |
88 |
> Secondly, the merge commits (i.e. top |
89 |
> commits that are verified |
90 |
> by Portage) are signed by dedicated key that |
91 |
> is part of the infra key |
92 |
> set. In other words, it works out of the box. |
93 |
> |
94 |
> |
95 |
> Is there any documentation that shows users how |
96 |
> to migrate to git, and |
97 |
> what the pros and cons might be? Maybe its |
98 |
> worthy of its own news item. |
99 |
> |
100 |
> |
101 |
> Maybe. I don't really know, and don't think it's a |
102 |
> good idea to show 30 |
103 |
> news item of things users might like on every new |
104 |
> Gentoo install. |
105 |
> |
106 |
> |
107 |
> Well if instructions for setting up git sync and |
108 |
> associated pros/cons |
109 |
> are not documented anywhere then I won't advise anyone |
110 |
> to use it. |
111 |
> |
112 |
> |
113 |
> I've attempted to configure it for myself, and this is what |
114 |
> it does: |
115 |
> |
116 |
> * Using keys from /usr/share/openpgp-keys/gentoo-release.asc |
117 |
> * Refreshing keys from keyserver ... |
118 |
> [ ok ] |
119 |
> * No valid signature found: unable to verify signature |
120 |
> (missing key?) |
121 |
> |
122 |
> |
123 |
> |
124 |
> Please report a bug and attach your configuration along with keyring |
125 |
> version. |
126 |
> |
127 |
> |
128 |
> It works after upgrading to openpgp-keys-gentoo-release-20180706 from |
129 |
> openpgp-keys-gentoo-release-20180323. |
130 |
> |
131 |
> |
132 |
> Does Portage not call attention to critical updates? |
133 |
|
134 |
No, but that might be a nice feature. We'd have to introduce some kind |
135 |
of standard mechanism via PMS or a GLEP. |
136 |
|
137 |
> It used to make a special statement for a new stable Portage and |
138 |
> strongly recommended that it be emerged first. It should probably do the |
139 |
> same for openpgp-keys-gentoo-release. |
140 |
|
141 |
Sure, but it this case we have a chicken-and-egg problem, because I |
142 |
needed the latest openpgp-keys-gentoo-release installed but in order to |
143 |
do that I had to sync, but then verification failed because I didn't |
144 |
have the latest openpgp-keys-gentoo-release. |
145 |
-- |
146 |
Thanks, |
147 |
Zac |