In this structure I've merged the container into this repo. We create a repo
which contains all of our dependencies, including PyGithub, nginx, and
nss_wrapper. We also copy the commands to be run into the container. How does
this work?
First, we generate a certificate to use for nginx. This certificate lies and
says it is api.github.com.
Second, we install the fraudulent certificate into the system certificate
store. All processes will now trust this certificate.
Third, we start a local nginx instance using the fraudulent certificate.
Fourth, we use nss_wrapper to lie to the python scripts about the IP address of
api.github.com. This will always resolve to 127.0.0.1.
When the python scripts try to find api.github.com, it will resolve to
127.0.0.1. When they connect to nginx they get a certificate that claims to be
api.github.com. They trust this certificate. The nginx instance gets the
request, forwards it to the real api.github.com and caches the result. Future
fetches come from the cache.
In this structure I've merged the container into this repo. We create a repo which contains all of our dependencies, including PyGithub, nginx, and nss_wrapper. We also copy the commands to be run into the container. How does this work?
First, we generate a certificate to use for nginx. This certificate lies and says it is api.github.com.
Second, we install the fraudulent certificate into the system certificate store. All processes will now trust this certificate.
Third, we start a local nginx instance using the fraudulent certificate.
Fourth, we use nss_wrapper to lie to the python scripts about the IP address of api.github.com. This will always resolve to 127.0.0.1.
When the python scripts try to find api.github.com, it will resolve to 127.0.0.1. When they connect to nginx they get a certificate that claims to be api.github.com. They trust this certificate. The nginx instance gets the request, forwards it to the real api.github.com and caches the result. Future fetches come from the cache.