-----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 <m...@canonical.com> > wrote: >> On 16 September 2011 12:51, Michael Hudson-Doyle >> <michael.hud...@linaro.org> 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@lists.launchpad.net 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----- _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
