| 1 |
Hi, |
| 2 |
|
| 3 |
On Sun, 13 Dec 2015 18:36:51 +0100 Patrick Lauer wrote: |
| 4 |
> Oh hey. We're in the future. Let's try to commit something to |
| 5 |
> repo/gentoo.git! |
| 6 |
> |
| 7 |
> So apparently we're signing things with gpg now, so let's read the |
| 8 |
> official documentation. |
| 9 |
> The [1] wiki seems to be the canonical location for such things. |
| 10 |
> |
| 11 |
> Oh dear. The layout is VERY broken. See [2]. Which redirects to [3], |
| 12 |
> which is a duplicate of [4], which has been closed because apparently |
| 13 |
> the persons responsible don't understand how to internet. |
| 14 |
> Since this bug is only about a year old I don't expect any progress soon |
| 15 |
> - but fetching random crap from untrusted hosts is not a sane option. |
| 16 |
> Especially since there is already a webserver, which is also trusted, so |
| 17 |
> I'm confused why we're still having this conversation. |
| 18 |
> |
| 19 |
> But hey, let's blindly fetch CSS from unknown, just to notice that this |
| 20 |
> 'theme' needs JavaScript to display properly. Because reasons. |
| 21 |
> |
| 22 |
> Why would I want to blindly execute code when reading the text of a |
| 23 |
> wiki? Because, reasons. Because, future! |
| 24 |
|
| 25 |
I agree with you that wikification of the documentation brings |
| 26 |
security risks, especially due to sourcing of not-so-trusted |
| 27 |
resources. But anyway wiki is just docs, one can read them in any |
| 28 |
isolation environment of choise. Of course, javascript powered L3 |
| 29 |
cache attack may extract ones git key, this kind of attack may |
| 30 |
happen from any js-enabled site. So if someone prefers to go for |
| 31 |
such high security levels, a physically isolated box should be used |
| 32 |
for git purposes only — and this is what Linus does IIRC. Rackcdn |
| 33 |
js is not an additional risk in real-life conditions IMO. |
| 34 |
|
| 35 |
Also wiki is barely readable in the lightweigth (and rather secure |
| 36 |
due to lack of extra functions) browsers like elinks or lynx. This |
| 37 |
irritates me, but is still tolerable in this imperfect world. |
| 38 |
|
| 39 |
> Since signing is mandatory since the git migration, ahem, this means |
| 40 |
> that no one in the last 5 months(!) actually followed the documentation |
| 41 |
> (because that does NOT work!). I'm almost impressed, but, wow, this is |
| 42 |
> enterprisey. |
| 43 |
|
| 44 |
It is absolutely possible to create correct gpg key, put it into |
| 45 |
LDAP according to GLEP and to sign commits and pushes properly. |
| 46 |
What is not currently possible is to verify all tree automatically. |
| 47 |
|
| 48 |
I agree that gkeys needs more work. But we are all volunteers here. |
| 49 |
You may help them if you are that interested into this |
| 50 |
functionality. |
| 51 |
|
| 52 |
What worries me more that we still have no way for rsync users to |
| 53 |
verify the portage tree (or Gentoo tree in the newspeak someone |
| 54 |
prefers here). And most users use rsync. |
| 55 |
|
| 56 |
> So, what can we do to make this whole story of 'commit (and push) to |
| 57 |
> repo/gentoo.git' make sense? And why do I appear to be the only one to |
| 58 |
> notice this chain of breakage?! |
| 59 |
|
| 60 |
We need to complete gkeys project, right? That's not all of the |
| 61 |
story, but a start. So send patches :) As for the full story, we |
| 62 |
still need to somehow verify rsync tree. For now only snapshots are |
| 63 |
verified. |
| 64 |
|
| 65 |
Best regards, |
| 66 |
Andrew Savchenko |
Archives