Page:
Summit2Day2
Pages
AboutUs
Accounting
AccountingDesign
AdvancedInstall
AllmydataDotComPage
ArchLinuxArmInstallation
BBFreeze
BadContent
Bibliography
BitCoinPage
BuildSystemTheory
BuildbotPolicy
Capabilities
CodingStandards
CompileError
ComponentDefinitions
Convergence Secret
DelegationOperations
Dev
DevInfra
DirectoryNode
Doc
DownloadDebianPackages
Extensions
FAQ
FileId
FileTree
GSoCIdeas
GSoCIdeas2009
GSoCIdeas2010
GridBackup
GridManager
Grids
Home
HowToReportABug
HowToWriteTests
HowtoBuildPyCryptoOnWindows
HowtoContributeABuildbot
InstallDetails
Installation
JavaScript
Keywords
KnownIssues
LocalGrid
Manual
MeetingNotes_2012_10_23
MemoryFootprint
MoveOffTrac
Munin_Stats Gatherer_Readme
Munin_local_plugins_README
NewAccountingDesign
NewCapDesign
NewImmutableEncodingDesign
NewMutableEncodingDesign
NewbieDeveloperSetup
News
OSPackages
OldNews
OneHundredYearCryptography
OriginalWikiStart
Ostrom
Packaging
PatchReviewProcess
Patches
PeerSelection
Performance
PkgSrc
Proposed
Python3
QuotaManagement
RelatedProjects
RequestedEdits
ResearchVenues
SNARKs
Security
ServerSelection
SftpFrontend
SpamPolicy
StorageIndex
Summit
Summit1
Summit2011
Summit2016
Summit2Day1
Summit2Day2
Summit2Day3
Summit2Day4
TaggedHash
TahoeLAFSMobile
TahoeLAFSWeeklyNews
TahoeThree
TahoeTwo
TahoeVsDebianBuggyOpenSsl
TestGrid
TipsTricks
TracSecurityOverview
TracStartingPoints
TracWikiMacros
Tutorial
UbuntuPackaging
UseCases
VerifierId
VersionNumbers
Versioning
ViewTickets
ViewTickets2
VolunteerGrid
WeeklyMeeting
WindowsBuild
apparmor
pyFilesystem
test
3
Summit2Day2
warner edited this page 2011-11-12 22:05:58 +00:00
Table of Contents
2nd Summit Day 2
09-Nov-2011, Mozilla SF. Video (1.1GB flash .flv, 4 hours)
Attendees
- Zack Weinberg
- Zooko
- David-Sarah
- Brian
- Shawn
- Mark Seaborn
Ideas
- Shawn: would be nice to have a more traditional username/password web frontend
- I (warner)'m imagining an IService, listening for HTTP on a different port than the main WEBAPI port, with a public URL. You submit username+password, get a cookie, present a filename. The gateway translates that into a filecap.
- maybe store one rootcap per username. use bcrypt/scrypt to defer exposure until user submits password.
- adding ACLs: either put a table in the frontend (username->file list), or put ACL data in dirnode edge metadata and have frontend compare it against a username
- sharing to public: tell frontend a filename/dirname and ask to make it public, it returns a tinyurl. Just like a tinyurl except it's a proxy instead of a redirect.
- sharing to an individual: maybe have an encryption pubkey for each account, Alice tells frontend "share my ~/foo with user=Bob", frontend encrypts a note to itself with Kbob, later when Bob logs in, his password bcrypt-unlocks the decryption key Kbobpriv, decrypts the note, gets the dircap, adds to a table for Bob, lets him enumerate a list of inbound shared directories
- zwol describing a Tor project, making Tor traffic look like other traffic: WoW, other web browsing. "Stegatorus"?
- zwol thinking about censorship-resistance, content-centric networking
Control Panel
- Brian explained requirements for a tahoe web-control-panel:
- examine/control Agent things like periodic backup jobs (local dir,
dircap, schedule, status, progress), lease-renewal/repair jobs
(dircap, schedule, status, progress)
- not using browser ambient authority, accessed through NODEDIR (iff
you can read/write to NODEDIR/private, you should be able to get to
the Web Control Panel),
- not scoped to a particular filecap/dircap
- yes scoped to "client authority" (i.e. an "Account", q.v. Accounting,
for general uploads and maybe repair), or local-disk-authority
(backup jobs), or server admin (for the server side of Accounting)
- ok to have no-JS and yes-JS options, ok if the no-JS option is less
pleasant
- David-Sarah, Zack, Shawn designed a scheme
- writes a "control.html" into NODEDIR/private/
- "tahoe control" launches browser with `file://.../control.html`
- yes-JS version:
- it contains one big `<iframe src="<http://WUI/control#SECRET>">`
- that page contains JS which pulls the secret out of the fragment,
then does lots of XHR with the secret to present the control panel
- no-JS version:
- it contains a form with a big "Start" button and a secret in a
hidden form-post argument
- that returns a page with lots of forms, secrets in hidden
post-args. All links are POSTs. "back" won't be pleasant (requires
a 're-submit form?' confirmation each time).
- benefits: keep secret out of address bar, out of Referrer header
- other useful techniques:
- to limit the lifetime of a powerful secret, 'tahoe control' can write
a new secret into NODEDIR just before launching the browser, and the
node can erase or change the secret just after accepting the
resulting browser hit.
- splitting the webapi into multiple origins is becoming more
important: probably starting with one port for (control-panel,
welcome, node-status, WUI-dirnodes, download-only WAPI), and a second
one for (WUI-documents) that could be executable.
- [whiteboard](../raw/attachments/Summit2Day2/day2-webcontrol.jpg)
Accounting Review
- Brian presented his Accounting branch
(<https://github.com/warner/tahoe-lafs/tree/accounting>) , only looking
at the delta between the '466-ed25519' branch and the 'accounting'
branch (it builds upon the #466 work)
- deferred discussion of leasedb crawler and race conditions, that
requires more serious design work. David-Sarah and Brian will huddle on
it, probably online later
- approach seemed good, code is still incomplete
- needs: more tests, usable control panel, refinement of "account
message" concept
- need to carefully plan the merge with LAE's s3-backend: they overlap a
lot. Removing leases from shares helps a bunch. s3-backend introduces
async share-crawlers, accounting removes one big crawler but adds a new
small one, which might need to be async-ified if that still seems like
a good idea.
- consensus was that #466 should definitely land first. But then whether
accounting should land before s3-backend, or other way around, was
unclear. accounting needs more development work before it's ready for
landing, s3-backend might be closer. But some co-evolution and
anticipatory refactoring should make things easier for everybody.
- brief discussion about branches in Git vs Darcs, specifically for
working on projects like this. Brian anticipates pain and suffering
trying to test merges of s3-backend (managed in a darcs branch) with
his accounting work (managed in git branches). David-Sarah suggested
applying the git/darcs bridge on a branch too, brian skeptical.