heimdal: update to 7.8.0

[dscho]

This closes git-for-windows/git#4118

[dscho]

dscho deployed to build-pacman-packages 4 hours ago

Let's see what will happen when I deploy the x86_64 build...

[dscho]

dscho deployed to build-pacman-packages 4 hours ago

Let's see what will happen when I deploy the x86_64 build...

As I thought. It's now marked as "Inactive".

I guess the standard model of deployments via workflows is that you first build all your artifacts, then deploy them all in another workflow run.

The problem with that model is that the mere act of using an environment is already considered as constituting a deployment, and environments are the only way to guard secrets behind manual gates, which is something I want to do with that package signing.

And it does not seem as if you can sign Pacman packages after building them, only while building them (the --sign option of makepkg seems to be the only way to sign them, the --sign option of repo-add does not sign the packages, it only signs the package database, i.e. the index of available packages).

This poses a problem: The only deployment model available to us appears to be incompatible with Pacman's package building/signing process.

[dscho]

And it does not seem as if you can sign Pacman packages after building them, only while building them (the --sign option of makepkg seems to be the only way to sign them, the --sign option of repo-add does not sign the packages, it only signs the package database, i.e. the index of available packages).

Hmm. It looks like I was wrong on that one. Judging by this code and this code, all makepkg --sign does is to call:

	gpg --detach-sign --use-agent "${SIGNWITHKEY[@]}" --no-armor "$filename" &>/dev/null || ret=$?

So I guess that this part of pacman-helper.sh quick_add is good enough and we can adjust the deployment processes of Git for Windows to adhere to the way GitHub workflows requires to function.

[dscho]

Having said that, the code-signing of the executables inside the Pacman packages is still something that needs to be done during the build. I am currently not sure how to deal with that issue.

[dscho]

The deployments worked, and I will have to think more about approaches how to move them completely to GitHub workflows. But I can do that elsewhere, no need to "hold this PR hostage", i.e. I will merge it.