id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
133	flappclient can expose swissnums on error	Brian Warner		"If a flappclient command uses a FURL that has a slightly corrupted swissnum, or if some temporary server-side problem causes that swissnum to not be known, then the !KeyError traceback will reveal the swissnum that it tried to use.

One of the goals of using {{{flappclient --furlfile}}} is to hide the furl from a process that is watching the client's output (like a buildbot step log). So exposing the secret this way is a problem.

This isn't specific to flappclient: other foolscap-using programs which encounter this sort of error will hit it too.

I suppose it's not a huge issue, because it's difficult to get into this situation: you must actually connect to the right server first (if the location hints or the tubid are wrong, it displays a different error message which does not include the swissnum). So it's either going to be a corrupted swissnum in your FURL, or an ephemeral FURL that the server no longer remembers (and therefore is unlikely to still be useful to an observer). The most important case would be if the server temporarily doesn't know about the swissnum, perhaps if there is a gap between the Tub being started and the persistent Referenceables being registered.

The fix is probably to change the exception to not include the swissnum, or only include its hash. I originally thought it would be useful to display the swissnum so you could figure out exactly which getReference was having the problem.. but I'd have to think about it, whether that's really helped me debug any problems recently.
"	defect	closed	major	0.5.0	negotiation	0.4.1	fixed