launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #06276
CodeBrowse: The Path Forward
-
To:
launchpad-dev@xxxxxxxxxxxxxxxxxxx
-
From:
Max Kanat-Alexander <mkanat@xxxxxxxxxxxx>
-
Date:
Tue, 25 Jan 2011 17:45:13 -0800
-
Organization:
Bugzilla Project
-
User-agent:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7
Hey folks! The next step for improving codebrowse is to get loggerhead
trunk running on launchpad. This will require the following things:
1) Improve the test suite coverage for loggerhead so that we have fully
automated tests that prove that it works, and don't have to worry about
deploying new technologies into production.
Currently some of the existing tests fail. Also, I suspect that the
test suite needs more coverage--particularly for all the various
combinations of options that loggerhead can take. (For example, tests
should be run with and without the on-disk cache.)
2) Once this is done and we're sure that it's stable, I'd like to
release that as loggerhead 1.19. The general bzr community would benefit
from a faster, better loggerhead as well as Launchpad benefiting from
it. The NEWS file needs to be updated before this happens, though--it
wasn't quite kept up to date with the trunk changes as they were checked in.
3) Develop a solid plan and implementation for history_db to run on
codebrowse. I don't know much about the IT architecture of codehosting
and codebrowse, but I did talk to jam about this a bit. The *ideal*
solution would be that codehosting updates history_db itself whenever
there is a push to a branch, and that loggerhead uses the history_db
that is in those branches. Perhaps the updating of history_db could be
done asynchronously by codehosting after the branch is updated, in order
to not slow down commits or pushes.
jam would be the person who would probably know the most about what
needs to be done here--I didn't do any work on history_db.
4) Comment out and disable the /raw/ controller in loggerhead, just for
the launchpad instance of it. Don't add an option to disable it, just
comment out the code. (I'd like to avoid a tremendous proliferation of
command-line options for loggerhead's serve-branches script, and all
you'd have to do is comment out one line of code and a few lines of
template.)
5) Deploy loggerhead 1.19 with history_db.
6) Make the /raw/ controller safe for codebrowse by allowing codebrowse
to use launchpad's time-limited token system.
loggerhead serves raw file content on a separate domain, to prevent XSS
attacks. This means that for codebrowse's private branches, some system
is needed to authorize access to raw private branch data. I assume that
the launchpad team is already familiar with how to do this thanks to
methods of accessing private attachments in librarian. (Basically, you
generate a token, redirect to the actual content page with the token as
a URL parameter, then check the token and delete it from the database
before displaying the actual content. It's a one-use token that proves
that you are authorized to access the content.)
The problem is that authentication data other than the token shouldn't
go to raw files, because that authentication data could be used by XSS
attackers.
I'm available for discussions and planning of how all of this work is
going to happen, but the work itself will be done by the Launchpad team,
as I understand it from my discussions with Martin.
-Max
--
http://www.bugzillasource.com/
Competent, Friendly Bugzilla, Perl, and IT Services
Follow ups