mitmproxy VS dive

A great way to test the effectiveness of a pinning implementation is by simulating an MITM attack. Tools like Mitmproxy or Wireshack allow us to create a test environment to monitor, intercept, and proxy network requests for a test host.

Actually, reading the issue I think the IBM request is a lot more reasonable than this tweet makes it seem.[1] The issue is essentially that a mitmproxy dependency has a CVE, mitmproy updated the dependency (in March), but hasn't made a stable release yet with this update, and IBM guy is asking "when do you plan to tag a release? Do you have a timeline for this?"

Notably it's NOT asking for a fix; "when will you fix it?" is not accurate as there is nothing to be fixed. It's just asking "when do you plan to make a new release with this dependency update?"

[1]: https://github.com/mitmproxy/mitmproxy/issues/6051

https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...

update

mhils: "@FrugalGuy has just sent me genuine apology, which I truly appreciate. Please be nice and assume good intentions. :heart: "

https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...

You can programatically extract XHR request URLs: https://github.com/wkeeling/selenium-wire#intercepting-requests-and-responses It uses https://github.com/mitmproxy/mitmproxy which you could also script.

Once you uninstalled mitmproxy go to https://mitmproxy.org

In /etc/hosts file you put only IP addresses and hostnames, i.e. 127.0.0.1 cdn.cloudflare.steamstatic.com. Then you have to set up a web server on localhost port 80 and put your image at http://localhost/steamcommunity/public/images/apps/753/1d0167575d746dadea7706685c0f3c01c8aeb6d8.jpg as well as other files from https://cdn.cloudflare.steamstatic.com. You also have to keep the URLs updated when they change upstream. It's not worth it. Better use a local proxy server like mitmproxy or requestly.

Dive is a great tool for debugging this. I like image reduction work just because it gives me a chance to play with Dive: https://github.com/wagoodman/dive

One easy low hanging fruit I see a LOT for ballooning image sizes is people including the kitchen sink SDK/CLI for their cloud provider (like AWS or GCP), when they really only need 1/100 of that. The full versions of both of these tools are several hundred mb each

Whether you work with Docker regularly or even create your own Docker containers, Dive is a great tool for streamlining image sizes, potentially helping you save storage costs and speed up deployments.

If you’re happy to pull the image, then sort of yes. You can either use docker inspect or a tool like dive (https://github.com/wagoodman/dive) to see how each layer was created. This will give you an idea of the Dockerfile.

Also, check out dive. It is an amazing tool for examining containers and find your size issues.

Did you try using dive ? It allows you to see each layer, so you can see the files that are added

I like this tool: https://github.com/wagoodman/dive

Also do I get shiny flair for https://github.com/wagoodman/dive/pull/443? Perhaps "Void shouter"?

This tool is really useful for showing the size of each layer, making it obvious which layer is blowing up your image size: https://github.com/wagoodman/dive