id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
1593	the drop-upload dircap should be in BASEDIR/private/	zooko	davidsarah	"We like to keep anything confidential out of {{{~/.tahoe/tahoe.cfg}}} and in {{{~/.tahoe/private/}}}. This allows people to share their {{{tahoe.cfg}}} or an excerpt from it without risking disclosure of sensitive information. Unfortunately the dircap for the ""drop upload"" feature is currently stored in {{{~/.tahoe/tahoe.cfg}}}. To close this ticket, start reading that dircap out of {{{~/.tahoe/private/}}} and deprecate its appearance in {{{~/.tahoe/tahoe.cfg}}}.

Decisions we have to make while doing this:

1. Where does it appear in {{{~/.tahoe/private/}}}? I would recommend its own file, perhaps named {{{~/.tahoe/private/drop-upload.cap}}}.

2. How to handle if you detect a cap in the old location in {{{tahoe.cfg}}}, in a key named {{{[drop_upload]upload.dircap}}}? I suggest to raise an error, similar to the way we do [source:trunk/src/allmydata/node.py?annotate=blame&rev=5123#L136 if an old-style config file is detected].

== “'Twere well it were done quickly” ==

Since drop-upload was explicitly marked as an ""experimental"" feature in v1.9.0 that we reserved the right to change in backwards-incompatible ways, we shouldn't worry too much about forcing users who have already started using it to change their config files if they want their Tahoe-LAFS gateway to start up. But, the longer we leave it there, the more people will come to rely on it, and the more we'll feel like we ought to go through the long process of gracefully deprecating it in its old location before finally, years later, removing it altogether. So let's hurry and remove it altogether now!

"	defect	closed	major	1.9.2	code	1.9.0	fixed	configuration security forward-compatibility