Comment # 7
on bug 9234
from Guy Harris
(In reply to comment #0)
> Now, I'm not as familiar with Wireshark's code as anyone reading this
> probably would be, but since Tshark can get all the way to the protocol
> container and accurately read and print out the value of the field, it can
> already do what others are trying really hard to do, and I would think
> (perhaps naively) that an edit operation on the field that tshark identified
> would be somewhat arbitrary.
Maybe.
For some traces, randomizing fields tagged for sanitization might do the job,
but, for other traces, you might want some semantics attached to that, e.g. if,
the first time the path name "\sballmer\Resignation Letter.docx" was seen in an
SMB access to a given host, it was replaced with
"\xyzzyfff\mumblefrotzsqueakx.docx", all subsequent occurrences of
"\sballmer\Resignation Letter.docx" in that trace should be replaced with
"\xyzzyfff\mumblefrotzsqueakx.docx", so that somebody looking at the trace
knows what references are being made to a particular file without easily
inferring something from the file's name.
However, sanitizing file *data* consistently would be harder, but would be
important as well; perhaps it's not worth trying to do that in a fashion that
would let you see whether, for example, reads from a file are returning data
that you previously wrote to the file. (There might be ways of doing that, but
now your sanitizer starts emulating an SMB server....)
I suspect packet sanitization could turn into an open-ended project, with, at
any stage in the project, a significant number of users saying "it's nice as
far as it goes, but I really need it to do XXX". That doesn't mean letting the
best be the enemy of the good, although it does mean that we may have to say
"yeah, someday, but probably not any time soon unless you write it yourself" to
some enhancement requests.
You are receiving this mail because:
- You are watching all bug changes.