Opened 15 years ago
Closed 14 years ago
#133 closed defect (fixed)
flappclient can expose swissnums on error
| Reported by: | Brian Warner | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 0.5.0 |
| Component: | negotiation | Version: | 0.4.1 |
| Keywords: | Cc: |
Description
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.
[7b7e1b0ec403e2a1be9efa5e5465dd9d7226f61e] should close this: I changed it to only log the first two letters of the swissnum, as a hint to tell you which FURL you were using without exposing too much information.