Open kquinsland opened 2 months ago
I have a fix but it's currently only applied to the various apt
calls. I am not currently in a good position to figure out the -o Acquire::https::Verify-Peer=false
equivalent for the other package managers.
The .patch
containing the fix is attached.
My question: Should I open a PR with just this fix or not bother until similar is implemented for the other package managers, too?
@kquinsland I believe you are expecting more from these flags than is the original intention, from the script
360 -I If set, allow insecure connections while downloading any files. For
361 example, pass '--no-check-certificate' to 'wget' or '--insecure' to
362 'curl'. On Debian and Ubuntu, using this option with -U allows obtaining
363 GnuPG archive keys insecurely if distro has changed release signatures.
.
.
378 -l Disable ssl checks. When passed, switches "https" calls to "http" where
379 possible.
The -l
merely alters https handling, as shown here
825 # Check the _DISABLE_SSL value and set HTTP or HTTPS.
826 if [ "$_DISABLE_SSL" -eq $BS_TRUE ]; then
827 HTTP_VAL="http"
828 else
829 HTTP_VAL="https"
830 fi
The -I
is for handling communications insecurely, that is, curl, wget, etc.
839 # Handle the insecure flags
840 if [ "$_INSECURE_DL" -eq $BS_TRUE ]; then
841 _CURL_ARGS="${_CURL_ARGS} --insecure"
842 _FETCH_ARGS="${_FETCH_ARGS} --no-verify-peer"
843 _GPG_ARGS="${_GPG_ARGS} --keyserver-options no-check-cert"
844 _WGET_ARGS="${_WGET_ARGS} --no-check-certificate"
845 else
846 _GPG_ARGS="${_GPG_ARGS} --keyserver-options ca-cert-file=/etc/ssl/certs/ca-certificates.crt"
847 fi
In order to have it handle your special case of a MITM proxy, it might be better to provide a PR since this will provide a complete implementation (working example). Any PR submitted should also include tests which exercise the additional code.
Description of Issue/Question
Neither of the "insecure DL" options (
-I
and-l
) are carried over toapt
in most cases.In corporate environments it is common to both a) have all traffic go through a MITM proxy and b) not be able to get the MITM root CA loaded in some environments.
Because of this, it's common to see errors like this:
This is - unfortunately - expected. The man in the middle isn't trusted so
apt
- rightfully - refuses to pull.The simplest way to work around this is by adding a
-o Acquire::https::Verify-Peer=false
to theapt ...
command. Yes, I know that this can be put into the/etc/apt/config
but when that happens, it applies to everything everywhere all the time which isn't making an already sub-optimal situation better.In any case, the multiple
apt ...
calls inbootstrap.sh
don't immediately or explicitly fail in this case; bootstrapping does not report errors.Only after bootstrap is done and
salt-call
is run do I hit an error:While not ideal, a manual
pip install ...
should work, right?Nope, because
pip
never got installed becauseapt
skipped pulling packages for thehttps
repos.Setup
I am using the bootstrap.sh script with a ubuntu2204 container image. The specific args being fed are:
Steps to Reproduce Issue
I am using
kitchen
but the gist isubuntu:2204
container image withsalt-bootstrap.sh -l -I -X -P -D -p git -p nano stable
being run on a host where all traffic goes through a MITM proxy.Critically, the CA root for the MITM proxy is not loaded into the container environment so all
https
traffic appears to have a cert mis-match error.Versions and Systems