| 1 |
On Mon, 30 Mar 2015 05:37:01 +0000 (UTC) Duncan wrote: |
| 2 |
> Andrew Savchenko posted on Sun, 29 Mar 2015 21:04:52 +0300 as excerpted: |
| 3 |
> |
| 4 |
> > On Sun, 29 Mar 2015 19:52:38 +0200 Sebastian Pipping wrote: |
| 5 |
> >> On 29.03.2015 19:39, Andrew Savchenko wrote: |
| 6 |
> >> > On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: |
| 7 |
> >> >> So I would like to propose that |
| 8 |
> >> >> |
| 9 |
> >> >> * support for Git access through https:// is activated, |
| 10 |
> >> >> |
| 11 |
> >> >> * Git access through http:// and git:// is deactivated, and |
| 12 |
> >> > |
| 13 |
> >> > Some people have https blocked. http:// and git:// must be available |
| 14 |
> >> > read-only. |
| 15 |
> >> |
| 16 |
> >> They would not do online banking over http, right? Why would they run |
| 17 |
> >> code with root privileges from http? |
| 18 |
> > |
| 19 |
> > Gentoo tree access is not even near on the same security scale as online |
| 20 |
> > banking. |
| 21 |
> |
| 22 |
> The point is, if the gentoo tree is compromised and you install from it, |
| 23 |
> everything you run including that online banking is now effectively |
| 24 |
> compromised, so it most certainly *IS* at the same security scale as that |
| 25 |
> online banking. Weakest link in the chain and all that... |
| 26 |
|
| 27 |
The Gentoo tree is not verified anyway: mirrors distribute it via |
| 28 |
http, rsync and ftp. And using https for that will create a |
| 29 |
tremendous stress on mirror's CPUs, so this is a bad approach. |
| 30 |
Not to mention that https itself is very hapless protocol with tons |
| 31 |
of vulnerabilities (all SSL versions are affected and most TLS |
| 32 |
implementations). |
| 33 |
|
| 34 |
A proper solution will be to use cryptographic verification of |
| 35 |
downloaded files. Right now we have signed manifests and manifests |
| 36 |
can be used to verify all other data (ebuilds, distfiles, patches |
| 37 |
and so on). This is much more reliable solution, since it allows to |
| 38 |
verify data integrity even for compromised data channels or any |
| 39 |
infrastructure part not related to keys distribution or signing. |
| 40 |
|
| 41 |
What we really need is a tool to do such verification. This is work |
| 42 |
in progress now afaik. |
| 43 |
|
| 44 |
Best regards, |
| 45 |
Andrew Savchenko |
Archives