On Mon, Dec 01, 2014 at 05:49:35AM +0100, Sebastian Hahn wrote:
Hi Jason,
On 30 Nov 2014, at 23:32, Jason Cooper tor@lakedaemon.net wrote:
On Sun, Nov 30, 2014 at 06:48:09PM +0100, Sebastian Hahn wrote:
Access via https:// has been provided for years, and should continue to work without any hiccups.
No issue there for folks that prefer the extra layer.
My point is basically that there's no reason not to always use the extra layer.
Agreed.
If there are questions or concerns, let's here them.
My problem with cancelling access via git:// is that the alternative (https) trains new users to think they need to trust the server. The fact is they don't. They need to trust the person identifying himself as Nick Mathewson who holds the private key for 8D29319A.
We don't just have tor.git up there, a lot of repos don't include a single signed commit or even tag.
Yes, this is sad. And something I'm slowly working on.
You're right that trusting the server is nothing a good dev should do, but I'm also not worried about our demographic here.
Yes, and this is something that came to mind as I thought about it more. *I* like to pull git trees and build from scratch. But apparently that's not the norm any more (am I dating myself? :-P) I gave up on attending the local Unix/Linux group because they asked a room of ~35 "Linux fans" who had ever built their own kernel. Not a single hand...
So, yeah, we probably aren't training end users by requiring https://, because end users, sadly, are leet when they know how to do 'apt-get install ...' vice the Software Center.
On a tangent, referring to keys by their short (or long, for that matter) keyid is not a good idea. How to verify Nick actually has the blessing of the Tor project (or any subset of people therein, etc) to sign tags is yet another problematic area without a real solution.
Yes, using the 32bit identifier certainly is prone to collisions, but we also aren't attempting to validate that key in this thread. At the 2013 Kernel Summit, Linus advised using 12 characters for abbreviated commit hashes over the current norm of 7. Same problem, different aspect.
$ git config --add core.abbrev 12 #if you were curious
I know some folks like to use google hangouts to validate keys. Not that google is secure in any way, but the level of difficulty to intercept and modify an interactive audio/video stream makes it almost as good as face to face. Any live, interactive stream will do, if it's user-to-user encrypted, that's even better.
The one problem PGP keys *don't* have is the centralized authority infrastructure. Honestly, I much prefer the difficulty of validating PGP keys over the lack of control and forced trust you get with the CA system.
In conclusion: Yes, don't trust the server. I sleep a lot better pretending that people don't trust it.
Agreed.
I'd much prefer they be taught not to trust the path *or* the server.
Please consider restoring git:// access.
I have considered it, but my conclusion remains not to do it for now. Further discussion is invited.
No problem. Thanks for hashing it over with me.
thx,
Jason.