Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
Despite of all you're talking about is right from paranoid point of view, I'd, anyway, say DO NOT DO THAT, because you propose to revoke the right of choice from the users. It is user's decision, which protocol to use to fetch the sources. Although, you're, of course, free to make layman to fetch official repos from https, but not http/git protocols by default. Moreover, there are some times where it is impossible to fetch sources via secure way, but you need it right here and right now. В письме от Вс, 29 марта 2015 18:41:33 пользователь Sebastian Pipping написал: Hi! For the current Gentoo Git setup I found these methods working for accessing a repository, betagarden in this case: git://anongit.gentoo.org/proj/betagarden.git (git://git.gentoo.org/proj/betagarden.git) (git://git.overlays.gentoo.org/proj/betagarden.git) http://anongit.gentoo.org/git/proj/betagarden.git (http://cgit.gentooexperimental.org/proj/betagarden.git) git+ssh://g...@git.gentoo.org/proj/betagarden.git (git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git) Those without braces are the ones announced at the repository's page [1]. My concerns about the current set of supported ways of transfer are: * There does not seem to be support for https://. Please add it. * Why do we serve Git over git:// and http:// if those are vulnerable to man-in-the-middle attacks (before having waterproof GPG protection for whole repositories in place)? Especially with ebuilds run by root, we cannot afford MITM. So I would like to propose that * support for Git access through https:// is activated, * Git access through http:// and git:// is deactivated, and * the URLs on gitweb.gentoo.org and the Layman registry are updated accordingly. (Happy to help with the latter.) Thanks for your consideration. Best, Sebastian [1] https://gitweb.gentoo.org/proj/betagarden.git/ -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
Doesn't git:// uses SSH wich is secure? I think that was on github. git+ssh:// — does. git:// — does not. It is just git-daemon listening on separate port and serving plaintext, readonly (by default) access. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
GitHub does not support git:// but only secure protocols (HTTPS, SSH), GitHub DO (!) support git:// $ git clone git://github.com/msva/mva-overlay.git Cloning into 'mva-overlay'... remote: Counting objects: 10435, done. remote: Compressing objects: 100% (41/41), done. remote: Total 10435 (delta 11), reused 0 (delta 0), pack-reused 10393 Receiving objects: 100% (10435/10435), 2.99 MiB | 758.00 KiB/s, done. Resolving deltas: 100% (5132/5132), done. Checking connectivity... done. see [2]. shoud-i-use != do not support -- Best regards, mva signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
Hi! For the current Gentoo Git setup I found these methods working for accessing a repository, betagarden in this case: git://anongit.gentoo.org/proj/betagarden.git (git://git.gentoo.org/proj/betagarden.git) (git://git.overlays.gentoo.org/proj/betagarden.git) http://anongit.gentoo.org/git/proj/betagarden.git (http://cgit.gentooexperimental.org/proj/betagarden.git) git+ssh://g...@git.gentoo.org/proj/betagarden.git (git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git) Those without braces are the ones announced at the repository's page [1]. My concerns about the current set of supported ways of transfer are: * There does not seem to be support for https://. Please add it. * Why do we serve Git over git:// and http:// if those are vulnerable to man-in-the-middle attacks (before having waterproof GPG protection for whole repositories in place)? Especially with ebuilds run by root, we cannot afford MITM. So I would like to propose that * support for Git access through https:// is activated, * Git access through http:// and git:// is deactivated, and * the URLs on gitweb.gentoo.org and the Layman registry are updated accordingly. (Happy to help with the latter.) Thanks for your consideration. Best, Sebastian [1] https://gitweb.gentoo.org/proj/betagarden.git/
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/29/2015 06:41 PM, Sebastian Pipping wrote: Hi! ... * Why do we serve Git over git:// and http:// if those are vulnerable to man-in-the-middle attacks (before having waterproof GPG protection for whole repositories in place)? pedantOpenPGP (GPG is just one implementation)/pedant, but indeed, that is what the gentoo-keys project is about. There is experimental support for OpenPGP verification in portage already using gkeys. Currently the focus is on getting developer's keys up to GLEP63 specs, i currently see 36 good Gentoo developer keys. The scheme is also flexible enough to allow for overlays. Especially with ebuilds run by root, we cannot afford MITM. So I would like to propose that * support for Git access through https:// is activated, https is not a good protection against MITM when factoring in global PKIX CA setup, nor would it protect with regards to server compromise. So the only viable way to secure ebuild repositories is proper OpenPGP usage. - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJVGD9LAAoJEP7VAChXwav6VmsIALlhZ1g1GXYAL/ZkP+vi1L0H MLKfYcxkMgZNwEfykmRP4DvafNPDDhWT0gvFfD+vG4zucI7liQSUnzK8SbVtzz3l o/cCELtOvjq6pMnefizwxoG0IyJmu07Tu2kUPo3Qyw1I5IqHqaqFWDB/Noe5Rvuy rbXgWqMgg6rcYxOhUHN4YQFtw1xEgWW4CS8Smri2jjSRaizgQ2sw+Iji/ej4XUyW JvWdZfGfHuzTX/uWPr7ptyi9foVvTkc9Hko2t97XS/bNZvtECRNceZBOTGgHftgD nCopTHBY42G69B+z07qctdI2AH2ozskI1+42rE2k6vJLNfFcY5loidsWDPiG3a8= =9GQH -END PGP SIGNATURE-
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
They would not do online banking over http, right? Why would they run code with root privileges from http? 1) Actually, they will :( 2) Because they can't review what bank received via insecure channel, while they can review what they're themselves received via http/git. -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: So I would like to propose that * support for Git access through https:// is activated, * Git access through http:// and git:// is deactivated, and Some people have https blocked. http:// and git:// must be available read-only. Best regards, Andrew Savchenko pgpMY89uyP7TG.pgp Description: PGP signature
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On 29.03.2015 19:39, Andrew Savchenko wrote: On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: So I would like to propose that * support for Git access through https:// is activated, * Git access through http:// and git:// is deactivated, and Some people have https blocked. http:// and git:// must be available read-only. They would not do online banking over http, right? Why would they run code with root privileges from http? Best, Sebastian
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping sp...@gentoo.org wrote: Hi! For the current Gentoo Git setup I found these methods working for accessing a repository, betagarden in this case: git://anongit.gentoo.org/proj/betagarden.git (git://git.gentoo.org/proj/betagarden.git) (git://git.overlays.gentoo.org/proj/betagarden.git) http://anongit.gentoo.org/git/proj/betagarden.git (http://cgit.gentooexperimental.org/proj/betagarden.git) git+ssh://g...@git.gentoo.org/proj/betagarden.git (git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git) Those without braces are the ones announced at the repository's page [1]. My concerns about the current set of supported ways of transfer are: * There does not seem to be support for https://. Please add it. * Why do we serve Git over git:// and http:// if those are vulnerable to man-in-the-middle attacks (before having waterproof GPG protection for whole repositories in place)? Especially with ebuilds run by root, we cannot afford MITM. So I would like to propose that * support for Git access through https:// is activated, * Git access through http:// and git:// is deactivated, and * the URLs on gitweb.gentoo.org and the Layman registry are updated accordingly. (Happy to help with the latter.) Thanks for your consideration. Best, Sebastian [1] https://gitweb.gentoo.org/proj/betagarden.git/ Doesn't git:// uses SSH wich is secure? I think that was on github.
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On Sun, 29 Mar 2015 19:52:38 +0200 Sebastian Pipping wrote: On 29.03.2015 19:39, Andrew Savchenko wrote: On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: So I would like to propose that * support for Git access through https:// is activated, * Git access through http:// and git:// is deactivated, and Some people have https blocked. http:// and git:// must be available read-only. They would not do online banking over http, right? Why would they run code with root privileges from http? Gentoo tree access is not even near on the same security scale as online banking. Best regards, Andrew Savchenko pgpNDyzmTqg3y.pgp Description: PGP signature
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On 29.03.2015 19:56, Diamond wrote: Doesn't git:// uses SSH wich is secure? I think that was on github. git:// is the git protocol [1] with absolutely no authentication and no encryption. GitHub does not support git:// but only secure protocols (HTTPS, SSH), see [2]. Best, Sebastian [1] http://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#The-Git-Protocol [2] https://help.github.com/articles/which-remote-url-should-i-use/
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
pedantOpenPGP (GPG is just one implementation)/pedant, but indeed, that is what the gentoo-keys project is about. There is experimental support for OpenPGP verification in portage already using gkeys. Currently the focus is on getting developer's keys up to GLEP63 specs, i currently see 36 good Gentoo developer keys. The scheme is also flexible enough to allow for overlays. https is not a good protection against MITM when factoring in global PKIX CA setup, nor would it protect with regards to server compromise. So the only viable way to secure ebuild repositories is proper OpenPGP usage. I'd double that pedant paranoid! :) -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On Sun, Mar 29, 2015 at 1:52 PM, Sebastian Pipping sp...@gentoo.org wrote: On 29.03.2015 19:39, Andrew Savchenko wrote: On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: So I would like to propose that * support for Git access through https:// is activated, * Git access through http:// and git:// is deactivated, and Some people have https blocked. http:// and git:// must be available read-only. They would not do online banking over http, right? Why would they run code with root privileges from http? I don't see the point in disabling it. Certainly we should support ssl though. If people want to obtain their code over http they should be permitted to do so. Even without using ssl it is easy to just check that your commit hash is correct and it becomes as tamper-proof as sha1 (tell me again why the scm of the future is still using sha1?). -- Rich
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On Sun, 29 Mar 2015 23:35:54 +0600 Vadim A. Misbakh-Soloviov m...@mva.name wrote: Despite of all you're talking about is right from paranoid point of view, I'd, anyway, say DO NOT DO THAT, because you propose to revoke the right of choice from the users. A right of choice from the user only makes sense if there is a reasonable choice. Just to take this to the extreme: Should we add a heartbleed-enabled version of openssl back to the portage tree? It's the choice of the user if they want to have heartbleed enabled, right? If there is no disadvantage for the more secure protocols then there is no need for a choice. Moreover, there are some times where it is impossible to fetch sources via secure way, but you need it right here and right now. This has been said before, also in the thread about the webpage. Can you say what times that would be? Basically these days it's not possible to use the mainstream internet without https (you can't search google or log into facebook without https). I'd really like to hear of any real world situation where this is an issue. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpQ0bCBb3afe.pgp Description: OpenPGP digital signature
