make new introducer furls unguessable

[davidsarah]

In src/allmydata/introducer/server.py​, new introducer furls are created with the guessable swissnum "introducer".

New furls should instead be created as random, by omitting the "introducer" argument to ​tub.registerReference and using {{{ furlFile=os.path.join(self.basedir, "private", "introducer.furl") }}} instead. Existing furls will not change because introducer.furl will already exist, so this is backward-compatible.

The full security benefit is not obtained without #860, but there's no reason to continue generating guessable furls for new introducers in the meantime.

[zooko]

I guess this is a forward-compatibility feature because people who use it before we've landed this will have a persistent guessable furl, which could interfere with future access control features (#860).

[warner]

I'll try to write the patch for this over the weekend.. should be a simple use of tub.registerReference(ref, furlFile=) .

Hm. The introducer currently writes its furl to NODEDIR/introducer.furl, and our docs recommend copying it from that location to all the clients. To fit with out current pattern of putting all secrets in NODEDIR/private/, we should change that to NODEDIR/private/introducer.furl. Which is a pity, because if we used tub.registerReference(ref, furlFile=NODEDIR/introducer.furl), we'd get automatic backwards-compatibility: any existing nodes that upgrade to the new code will keep using their same old (guessable) FURLs, but new nodes will create a new (unguessable) FURL. And users could force the creation of a new (unguessable) FURL by just deleting introducer.furl and restarting.

I suppose the fix will be to this:

• if NODEDIR/introducer.furl exists and NODEDIR/private/introducer.furl does not, copy it into NODEDIR/private/introducer.furl
• then use furlFile=NODEDIR/private/introducer.furl

The only downside of that would be leaving the old NODEDIR/introducer.furl lying around, where it might get stale if the connection hints change. Anyone think we should delete the old one after copying it into private/ ?

[davidsarah]

Replying to warner:

The only downside of that would be leaving the old NODEDIR/introducer.furl lying around, where it might get stale if the connection hints change. Anyone think we should delete the old one after copying it into private/ ?

We should move the file into private/

[warner]

Oh, yeah, good point. So like this?:

• if NODEDIR/introducer.furl exists and NODEDIR/private/introducer.furl also exists, log a message and then delete NODEDIR/introducer.furl
• if NODEDIR/introducer.furl exists and NODEDIR/private/introducer.furl does not, move it into NODEDIR/private/introducer.furl
• use furlFile=NODEDIR/private/introducer.furl

[davidsarah]

Replying to warner:

• if NODEDIR/introducer.furl exists and NODEDIR/private/introducer.furl also exists, log a message and then delete NODEDIR/introducer.furl

Perhaps, print a message telling the user to delete one of them, and then exit.

• if NODEDIR/introducer.furl exists and NODEDIR/private/introducer.furl does not, move it into NODEDIR/private/introducer.furl
• use furlFile=NODEDIR/private/introducer.furl

+1

[warner]

please see the last patch on ​https://github.com/warner/tahoe-lafs/tree/1802-unguessable-introducer and review.

[David-Sarah Hopwood <david-sarah@…>]

In 9be1a94043ce1518:

Censor the introducer and helper furls' swissnums from the web welcome page. refs #1802

Signed-off-by: David-Sarah Hopwood <david-sarah@…>

[warner]

Local smoke tests look good. Thanks for taking case of the helper furl too!