Re: poudriere overlay: passing down git ENV variables (problem: self signed certificates)
Date: Wed, 03 Aug 2022 14:50:35 UTC
Choosing to not verify a certificate defeats the entire point of using the certificate and you may as well not use it at all. The better thing to do is trust it. Rather than try to take credit for someone else’s work in compiling a walk through, I’ll simply link a blog post that will give an example for git. https://jhooq.com/2-ways-to-fix-ssl-certificate-problem-self-signed-certificate-in-certificate-chain/#git-clone > On Aug 3, 2022, at 07:29, FreeBSD User <freebsd@walstatt-de.de> wrote: > > Am Wed, 3 Aug 2022 14:27:04 +0200 > Michael Gmelin <grembo@freebsd.org> schrieb: > >>> On Wed, 3 Aug 2022 12:38:26 +0200 >>> FreeBSD User <freebsd@walstatt-de.de> wrote: >>> >>> Hello, >>> >>> I try to acconplish tasks in maintaining ports via poudriere-devel's >>> OVERLAY option. First of all: >>> >>> it is a pain in the a... not having ANY suitable hint how to perform >>> this, a single line like that I found after a couple of hours >>> searching here: https://github.com/decke/ports would have been of >>> help, really. >>> >>> So, I'm facing the all-time-present problem of having my own git >>> server based on HTTPS with self signed certificate. git rejects >>> connecting to those servers in the default configuration setting. >>> Usually, I've to set via git config http.sslVerify false >>> to not verify the certificate. >>> Following the instructions given at https://github.com/decke/ports >>> with my existing poudriere setup incorporating a ports folder, >>> adjusting the URI with the one appropriate for my case, like: >>> >>> env GIT_NO_SSL_VERIFY=true poudriere ports -c -U >>> https://myname@my.server.de/git/ports.git -m "git+https" -B master -p >>> ov-freebsd >>> >>> fails with the well known "... problem: self signed certificate". >>> >>> Obviously poudriere is spawning its own environment within git >>> operates (so it seems to me) and is not passing the given environment >>> variable GIT_NO_SSL_VERIFY=true down to git. >>> >>> Now, I'm stuck here. I tried, anticpating that the "overlay port's >>> folder" will be located at the same root as my "head" foleder for the >>> port's collection will be rooted at, creating an folder "ov-freebsd" >>> and creating the .git folder and config file with git init --bare >>> ov-freebsd and then manually config this according to the >>> specifications given by the initial poudriere command as seen above - >>> does NOT WORK. It seems git is called to early or never access the >>> given preexisting folder - or I'm wrong in the assumption of the >>> location of the overlay folder. >>> >>> Also, checking out the "personal" git repo at the anticipated correct >>> location and configuring "http.sslVerify false" does not succeed as >>> expected. >>> >>> I guess this problem must be very common amongst those having their >>> own git repository servers backed via a webserver secured via SSL >>> self signed certificates, so I wonder whether there is a solution or >>> not. >>> >>> Can someone enlighten my? How can I pass the specified env varibale >>> down poudriere to git to achive the desired task? Assuming this >>> procedure is correct. If not, what is the proper way to achive that >>> task? >>> >> >> If you read /usr/local/bin/poudriere you see that it filters the >> environment. So neither GIT_NO_SSL_VERIFY will come through, nor HOME >> (which also means that git can't read $HOME/.gitconfig). >> >> The pragmatic solution would be to create a git wrapper script and tell >> poudriere to use it: >> >> cat >/tmp/git_wrap <<EOF >> #!/bin/sh >> GIT_NO_SSL_VERIFY=true git "$@" >> EOF >> chmod 755 /tmp/git_wrap >> echo GIT_CMD=/tmp/wrap >>/usr/local/etc/poudriere.conf >> >> Cheers >> Michael >> > > Thank you very much for the quick answer. > > Well, the approach is a bit "hacky", but it works, but I had to replace the part "[env] > GIT_NO_SSL_VERIFY=true" (which is obviously ineffectice and not working) with > > git -c http.sslVerify=false "$@" > > That written, brings up the question: > > is there a official way to pass down options to git as with "-c"? That would solve the hacky > wrapper script. > > Many thanks, > > Oliver > > -- > O. Hartmann >