CA file outdated

[ruben-herold]

hi.

after installing git for windows I try to access my git via https with letsencrypt certificate.
I got:

fatal: unable to access 'https://gitserver.test.de/repo': SSL certificate problem: certificate has expired

ssllabs confirmed that my certificate is valid. For me it looks like: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ is the problem.

after switching to schannel all workes fine. So please update the ca file

[PhilipOakley]

You forgot to search the closed issues (the issue search annoyingly provides the is:open condition; try deleting it ;-)

#3375 "Add the Let's Encrypt Root & Intermediate certificates to the installer" discussion is worth a review. I think It has the answer, though it's not my area.

HTH.

[rimrul]

Our certificate bundle includes the self-signed ISRG Root X1. And I can successfully connect to the letsencrypt X1 test server

openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443

Is your server potentially configured to distribute the cross-signed ISRG Root X1 as an intermediary?

[krilor]

Lets Encrypt will continue to serve the cross-signed chain as a default until Jan 11th ( https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html ). I see that users with DST Root X3 still in their CA bundle does have connectivity issues with connecting to services that use the default chain.

This is one of the reasons why it is removed from the ca-certificates packages ( https://ubuntu.com/security/notices/USN-5089-1 ).

I think it is wise to update the CA file in git-for-windows as well.

[rimrul]

Ok, taking a closer look at this, the changes to ca-certificates should be rather simple and I don't see much danger in blacklisting the expired certificate. mingw-w64-ca-certificates has diverged a bit from the msys2 package and might need some work, though.

[rimrul]

Lets Encrypt will continue to serve the cross-signed chain as a default until Jan 11th

That is January 11th 2021, though.

[rimrul]

The ca-certificates change is a PR now: msys2/MSYS2-packages#2653

The changes to mingw-w64-ca-certificates changes will follow after the msys2 team is happy with the PR.

[krilor]

Lets Encrypt will continue to serve the cross-signed chain as a default until Jan 11th

That is January 11th 2021, though.

Oh, my bad. I guess I found a bad/old reference. I was observing DST in the chain and went out find a reason for why :) guess I found a wrong one. Sorry. This might be a better reference: https://community.letsencrypt.org/t/providing-a-longer-certificate-chain-by-default/148738

What I am observing is that users using git with https on the default Lets Encrypt chain are hitting ssl cert expiry errors. Seeing it on git-for-windows and on Ubuntu. On ubuntu it was solved by updating CA certificates to get rid of the DST root.

[krilor]

The ca-certificates change is a PR now: msys2/MSYS2-packages#2653

The changes to mingw-w64-ca-certificates changes will follow after the msys2 team is happy with the PR.

Thanks for the quick turnaround :)

[dscho]

The changes to mingw-w64-ca-certificates changes will follow after the msys2 team is happy with the PR.

Seems it was merged 6h ago, and ca-certificates is listed on https://packages.msys2.org/queue as: "Ready for upload but waiting for dependencies"

[dscho]

@rimrul what's your plan regarding mingw-w64-*?

[rimrul]

Pulling it up to 20210119 and patching out DST X3, so that it's basically the same as ca-certificates.

[dscho]

Pulling it up to 20210119 and patching out DST X3, so that it's basically the same as ca-certificates.

Thank you for your untiring efforts! It was a good feeling to know you'd be holding down the fort while I was away.

[rimrul]

And here's the PR for mingw-w64-ca-certificates: msys2/MINGW-packages#9722

[rimrul]

Seems it was merged 6h ago, and ca-certificates is listed on https://packages.msys2.org/queue as: "Ready for upload but waiting for dependencies"

The CI picked it up for git-sdk-64, but not for git-sdk-32. It seems to be struggling with upstream msys packages a lot for git-sdk-32. The last update seems to be months ago, and that was a lot of packages at once.

[dscho]

It seems to be struggling with upstream msys packages a lot for git-sdk-32.

Upstream no longer builds MSYS packages for i686. If we want it, we have to build it ourselves.

But I'm not really sure we need to do that: the MSYS version is only relevant in workflows involving MSYS software such as Perl (used in git svn, for example). The MINGW version will be available also for i686, and the i686 version of Git is used mostly in scenarios like Visual Studio, where backwards-compatibility dictates the use of it (but git svn is not included there).

Having said that, in ARM64 setups, this might be relevant.

[rimrul]

The last update seems to be months ago, and that was a lot of packages at once.

And the reason is that that was the last and only time in 2021 any packages where uploaded to https://repo.msys2.org/msys/i686/.

I guess that means we'll have to keep track of all Msys2-Packages in the SDK in please.shand our component monitoring

[dscho]

I guess that means we'll have to keep track of all Msys2-Packages in the SDK in please.shand our component monitoring

I am loathe to do that: it would mean that we now have to maintain all of them, even the x86_64 variants. That'd add substantially to my maintenance burden.

Maybe we just keep it at ca-certificates, biting the bullet of adding that to the ever-growing list of my responsibilities?

[rimrul]

I don't like it either, but the mess is much bigger than ca-certificates. ca-certificates is any-arch. We could probably just point pacman at https://repo.msys2.org/msys/x86_64/ and have it download the any packages from there. But that doesn't solve the arch-dependent stuff. Take less as an example: git-sdk-64 has less 590, git-sdk-32 only less 581. Admittedly, not a huge difference right now, but they'll only drift further appart.

[dscho]

We could probably just point pacman at https://repo.msys2.org/msys/x86_64/ and have it download the any packages from there.

Is there any "any" package? I don't think so...

Take less as an example: git-sdk-64 has less 590, git-sdk-32 only less 581. Admittedly, not a huge difference right now, but they'll only drift further appart.

True. I hope we can abandon i686 soon. Visual Studio's support for i686 will end in 2025 or something like that.

[rimrul]

Is there any "any" package? I don't think so...

ca-certificates is any, some of the perl stuff might be any, I haven't had an exhaustive look yet.

I'll try to generate a list in a few hours.

I hope we can abandon i686 soon.

That'll be some work to get ARM64 into shape to not require it as a fallback anymore. Doable, but definitely work.

Take less as an example: git-sdk-64 has less 590, git-sdk-32 only less 581.

And Portable Git 2.33.0(2) includes different versions of less, depending on bitness.

[dscho]

You know what? It occurred to me that we can set up a new GitHub workflow to specifically build and upload i686 packages, without trying to upgrade their definitions to the latest component version. That way, we could sync, say, less/PKGBUILD with MSYS2's version, ensure that it builds for i686, push and have Actions take care of the rest. How does that plan sound to you, @rimrul ?

[rimrul]

Yes, that sounds like a reasonable idea. Most of the upstream packages probably build fine on i686, so that should work fairly well.

[rimrul]

I generated an overview of the diverging packages. It's all relatively close together, for now:

Package	git-sdk-64	git-sdk-32
asciidoc	9.1.1-1	9.1.0-2
bison	3.8.2-1	3.7.6-1
bsdcpio	3.5.2-1	3.5.1-1
bsdtar	3.5.2-1	3.5.1-1
ca-certificates(fixed for now through git-for-windows/MSYS2-packages#49)	20210119-3	20210119-1
diffutils	3.8-1	3.7-1
expat	2.4.1-1	2.3.0-1
filesystem	2021.06-2	2021.06-1
gdbm	1.21-1	1.19-1
git	2.33.0-1	2.32.0-1
glib2	2.68.4-1	2.68.1-1
grep	3.6-1	3.1-1
gzip	1.11-1	1.10-1
help2man	1.48.5-1	1.48.3-1
icu	69.1-1	68.2-1
info	6.8-1	6.7-3
lemon	3.36.0-2	3.36.0-1
less(fixed for now)	590-1	581-1
libarchive	3.5.2-1	3.5.1-1
libatomic_ops	7.6.12-1	7.6.10-1
libedit	20210714_3.1-1	20210522_3.1-1
libexpat	2.4.1-1	2.3.0-1
libgc	8.0.6-1	8.0.4-1
libgdbm	1.21-1	1.19-1
libidn2	2.3.2-1	2.3.1-2
libnghttp2	1.45.0-1	1.43.0-1
libp11-kit	0.24.0-1	0.23.22-2
libreadline	8.1.001-1	8.1.0-1
libsqlite	3.36.0-2	3.36.0-1
libssh2	1.10.0-1	1.9.0-1
libxml2	2.9.12-2	2.9.10-9
msys2-keyring	1~20210904-1	1~20210213-2
p11-kit	0.24.0-1	0.23.22-2
pacman	6.0.1-3	6.0.0-4
pacman-mirrors	20210902-1	20210703-1
patchutils	0.4.2-2	0.4.2-1
perl-HTTP-Cookies	6.10-1	6.09-1
perl-HTTP-Message	6.33-1	6.32-1
perl-IO-Socket-SSL	2.072-1	2.071-1
perl-libwww	6.57-1	6.55-1
python	3.9.6-1	3.9.5-1
texinfo	6.8-1	6.7-3
texinfo-tex	6.8-1	6.7-3
tzcode	2021c-1	2021a-1
vim	8.2.3441-1	8.2.2859-2

I have a prototype of an action to sync some packages from MSYS2 in my repo, but I'll need to review the list of packages we need to sync. I don't think we need all 200+ packages I currently have on my list (looking at those 11 versions of automake)

[dscho]

I have a prototype of an action to sync some packages from MSYS2 in my repo, but I'll need to review the list of packages we need to sync.

Quite honestly, I hope we can do with a more manual approach. But your workflow looks pretty good to me even so, so if you want to go for it, I'll merge it once you're ready. I'd just like to caution that asciidoc is probably not really crucial enough to merit the hassle of building the i686 MSYS packages for Git for Windows every time MSYS2 updates the package...

[rimrul]

Yes, I don't think I'll add asciidoc to the list. It's neither a package we bundle nor a package that's all that relevant to building Git for Windows. It just happens to be at the top of the table, because pacman -Q lists packages in alphabetical order.

I hope we can do with a more manual approach

I'm just thinking the semi-automatic approach can help us keep the package-maintenance burden reasonably low while also keeping the 32bit and 64bit releases as similar as possible, to prevent issues that only affect one version.

[dscho]

@rimrul okay, let's go for it.

[dscho]

The newest snapshot has the fix.

[cforce]

Issue is still existent

git --version
git version 2.36.0.windows.1

[rimrul]

Issue is still existent

git --version
git version 2.36.0.windows.1

No, DST X3 is not in the ca bundle for that version.