launchpad-dev team mailing list archive

[Michael Hudson-Doyle <michael.hudson@xxxxxxxxxx>]

On Fri, 16 Sep 2011 15:31:55 +0200, John Arbash Meinel <john@xxxxxxxxxxxxxxxxx> wrote:
> -----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.

Funnily enough, this is related to how I ended up implementing this.  I
wanted to know if it was possible to offer different authentication
strategies to different usernames, and then I found that most clients
start with auth_none (which includes a username), so you can support
anonymous access by just allowing auth_none to succeed for a particular
username...

> 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.

Ah yeah, I see what you mean looking at the code.  My code accepts any
authentication at all for the anonymous username though, so if bzr finds
a key and offers it, it will be accepted (without looking at the key at
all).  I guess this means that the user might get prompted to decrypt
their key and that could be a bit confusing.

All the above only applies if you're using paramiko for ssh of course,
openssh starts out with an auth_none request.  I guess bzr tries
key-based first as an effort to save a roundtrip?

Cheers,
mwh

> 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-----