Does it really makes sense to add this in a self-contained report?

Does it really makes sense to add this in a self-contained report?

For any network-heavy software being tested, pcap files are equivalent (if not above) in importance to logfiles, so I don't really have any doubt in a "yes" to that. Especially since that's just one (pretty wide) use case, there's probably a bunch of others. Trying to think of some others, testing (de-)serialization feels like something where attaching random binaries would be pretty useful too.

How would you consume that pcap file from the self-contained report? It's going to be base64 encoded.

But maybe I'm misunderstanding something here? @eqvinox

How would you consume that pcap file from the self-contained report? It's going to be base64 encoded.

But maybe I'm misunderstanding something here? @eqvinox

@BeyondEvil when you click the link for the file, the browser will open a file download dialog and save it decoded. (The download dialog would probably list wireshark too, as an application to directly open the file with. The file is first saved to /tmp for that, same way all "open with" downloads work.)

Ah, got it. Ok, I'll add this to next-gen. Thanks!

Missed this is during initial work of v4. Will try to get to it now.

How would you consume that pcap file from the self-contained report? It's going to be base64 encoded.
But maybe I'm misunderstanding something here? @eqvinox

@BeyondEvil when you click the link for the file, the browser will open a file download dialog and save it decoded. (The download dialog would probably list wireshark too, as an application to directly open the file with. The file is first saved to /tmp for that, same way all "open with" downloads work.)

I'm not seeing the behavior described here.

When I click the link, it just opens a new tab displaying the path to the binary.