| Thread Previous • Date Previous • Date Next • Thread Next |
On 05/11/2010 03:21 AM, Karl Fogel wrote:
In a nutshell: svn repo behind a thin connection, not meant to take a full server workload. Username/password is a great way to get the branch onto LP and available to the world, but our displaying the login to the public would be a blocker.If the user is worried about malicious denial-of-service stuff, then having anon access information published would be a problem. But a deliberate DoS is pretty unlikely, and they could avoid any accidental DoS by setting up a dedicated username/password pair just for Launchpad:
I don't know what the user is and isn't concerned about; it may just be general principle, or they may not have full control of this for whatever reason. But I could imagine, for instance, a spambot trying to read anything that looks like a URL, maybe using some library for recognizing URLs that's flexible enough for non-http URLs and login credentials. That could suddenly create a lot of spurious traffic... someday, if not necessarily today.
I haven't mentioned any of this in the Question #100519, because that user is still unaware of the new username/password feature entirely. But I think the above might address that users' concerns. IMHO, mirrored branches on Launchpad should show viewers all the information they'd need to reach the master source; otherwise they are put in the position of having to trust Launchpad. Dubious economic policy notwithstanding, Reagan still had it right with "trust but verify" :-). It's best if we offer users a way to verify.
I don't think I follow the argument here. What kind of trust are you talking about? If it's trust in honesty on our part, viewers already have to trust that we deploy the same code we publish, with no hidden tricks. If it's trust in timely synchronization, we have logs.
If it's trust in us making faithful copies, well, if there's a password on the master then the owner clearly wants it restricted. So the question of trust lies on that side, not on ours.
The main kind of trust I personally would worry about here is the blind trust that when you invite me to enter a password, you imply that you're not going to tell the world what it is(*). That's a blind trust in the sense that I might easily skip over any notices to the contrary unless maybe they're in big, red, bold flashing letters and accompanied by blaring sirens(**). By design we currently don't justify that trust.
Jeroen(*) Of course you may be mistaken or dishonest; whether what you're _really_ going to do also depends on how much I trust you.
(**) The kind the police use. With the other kind, it's pretty much a given that I'm going to be too distracted to read the notice.
| Thread Previous • Date Previous • Date Next • Thread Next |
