launchpad-dev team mailing list archive

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

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