launchpad-dev team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't know if this is relevant or not, but bzr follows the
recommended protocol and tries to "auth_none" to get the list of
supported protocols, and then do the real authentication. We did this
in order to allow 'bzr push lp:...' to not prompt the user for a
password that Launchpad won't support anyway.

I could be wrong about what 'auth_none' is versus your anonymous
authentication. It also looks like we try to do RSA and then DSA
authentication before we do auth_none. So maybe it wouldn't change
anything.

John
=:->

On 9/16/2011 5:49 AM, Michael Hudson-Doyle wrote:
> On Fri, 16 Sep 2011 13:02:56 +1000, Martin Pool <mbp@xxxxxxxxxxxxx>
> wrote:
>> On 16 September 2011 12:51, Michael Hudson-Doyle 
>> <michael.hudson@xxxxxxxxxx> wrote:
>>> Hi all,
>>> 
>>> While thinking about something else, I mostly accidentally
>>> implemented a potentially interesting feature for Launchpad,
>>> anonymous read-only ssh access to Launchpad:
>>> 
>>> https://code.launchpad.net/~mwhudson/launchpad/anon-ssh-hack/+merge/75442
>>
>>
>>> 
That's awesome, and an impressively small patch.  Thanks for jfdi.
> 
> Glad you like it :)
> 
>> A few thoughts: * this would be (I think 'should') be behind a
>> feature flag - it is a perfect example of something we might want
>> to deploy and then later turn off
> 
> Ah yes.  The fun here is that the ssh server does not connect to
> the database currently (is this still right?) so we'd need to add
> some private xml-rpc method to query the flag.  As wgrant points
> out, getting the scopes right for a general such method might be a
> bit tricky but for this particular use case it's trivial.  The
> premature optimizer in me wants to avoid making another XML-RPC
> call per log in too, but we can ignore him I think.
> 
> A somewhat scope aware feature flag method would also be useful for
> the forking server codehosting stuff I guess, so maybe I'll poke at
> that when I next get a free evening.
> 
>> * also, I think logging when people connect so that we can count
>> it would be well worth while (or perhaps it's handled at a
>> different level)
> 
> This is already there, due to other machinery:
> 
> $ tail -n5 /var/tmp/bazaar.launchpad.dev/codehosting-access.log 
> 2011-09-15 10:58:34,020 INFO [91675392] IPv4Address(TCP,
> '127.0.0.1', 52354) connected. 2011-09-15 10:58:34,078 INFO
> [91675392] +launchpad-anonymous logged in. 2011-09-15 10:58:34,087
> INFO [91675392] +launchpad-anonymous disconnected. 2011-09-15
> 10:58:34,087 INFO [91675392] disconnected. 2011-09-15 12:07:31,512
> INFO ---- Server stopped ----
> 
>> Those should both be a matter of just a few lines.
>> 
>> Much as the web is moving towards "ssl everywhere" I think doing 
>> everything over SSH has some substantial advantages: mitm
>> protection, and probably more often important protection against
>> non-malicious but clueless intervention by http proxies or other
>> firewalls, and also an integrity check against packet corruption.
>> (Though, if any of those things do happen, it can be confusing
>> for the user, but that's out of scope.)  So I would be happy with
>> this rather than bzr+http or bzr+tcp.
> 
> Cool.
> 
>> There is also a bit of a thing that people can now anonymously
>> make us spend a fair amount of cpu effort, and in the event there
>> is an exploitable attack in the smart server, they can get at it
>> without creating an account.  Obviously creating an account is
>> pretty easy, so perhaps it doesn't matter.
> 
> There is a difference between "pretty easy" and "trivial" when it
> comes to DoS I guess.  Less so for the exploit thing (more reasons
> for the feature flag).
> 
>> This also needs some ux consideration about when/how people use
>> this, or configure bzr to use it.
> 
> Yeah.  If successful, we could even get bzr to use it for lp:///
> urls when no username is configured (and thus not have lp: name
> resolution roundtrip to launchpad ever, which would be nice).
> 
>> But, I don't think that needs to block this.  I can imagine this
>> would be useful even just for cases where people very
>> specifically configure it, like for a CI server.
> 
> Yes indeed.
> 
> Cheers, mwh
> 
> _______________________________________________ Mailing list:
> https://launchpad.net/~launchpad-dev Post to     :
> launchpad-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> https://launchpad.net/~launchpad-dev More help   :
> https://help.launchpad.net/ListHelp


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5zT8sACgkQJdeBCYSNAAPacACcC6/XbCgZWNQiUiKvcmln2PHD
5jwAn1cTowPaAzRAoH8nIuJRdBtSAYk4
=q6xS
-----END PGP SIGNATURE-----