mintty: update to 3.6.2

[dscho]

This PR supersedes #61, using a branch in the git-for-windows/MSYS2-packages repository so that it can be branch-deployed from here.

See https://github.com/mintty/mintty/releases/tag/3.6.2 for details.

This closes git-for-windows/git#4114

[dscho]

Hmm... This PR is part of some investigation how to change Git for Windows' deployment processes, away from an opaque Azure Pipeline toward a more transparent, branch-deploying one. But...

It would appear that the "temporary (inactive) deployment" was the i686 one, and the x86_64 one was marked as "active". I guess we have to make this a matrix build that defaults to building for both architectures and then a dependent job deploying all the artifacts that have been built at the same time, much as the Azure Pipeline does that I am seeking to replace with a more transparent, fully GitHub-based solution.

[dscho]

Over at dscho#8 is the result of an experiment investigating whether we can use a "simple" workflow to automate opening these PRs, without needing to provide a separate token. Here is the workflow run: https://github.com/dscho/MSYS2-packages/actions/runs/3475076556

Sadly, the experiment kind of failed: since the PR is opened using the workflow's token, it cannot trigger other runs, including the CI builds. But we do want those builds to happen, to build confidence that the package can be built (and sometimes even testing the produced artifact) before starting the deploy.

I will have to think about ways how to adjust this workflow so that we can automate all of this.

One idea I have is to build a static web page (via gh-pages probably) that can be used to trigger workflow runs. It would take the specifics about which workflow to dispatch, and which inputs to use, as GET parameters (so that we can have automation generate those links e.g. to avoid snafus like this one where I triggered the correct workflow with the correct parameters but on an unintended branch).

Naturally, that static web page would need to pass a Personal Access Token to the workflow so that it can be used to open the PR. The trick will be to do all of this securely. An idea to make it super extra secure (which is probably overkill) is to do this:

• Add a GitHub App that is backed by an Azure Function, for the sake of generating OAuth tokens
• The static web page would then call out to the Azure Function to generate that OAuth token
• The OAuth token would be encrypted using the GitHub App's public key
• We would install the GitHub App's private key as a repository secret (or even environment secret, potentially guarded against unwanted usage) and the workflow would then use that private key to decrypt the OAuth token

Now that I've written all this up, it strikes me as a really complex and complicated solution to the problem. Hopefully I (or others) can think of better solutions.

A simpler alternative would avoid the GitHub App altogether and ask for a PAT (that the users have to generate themselves), pass that as a regular workflow_dispatch input, which would then be masked thusly:

on:
  workflow_dispatch:
    inputs:
      pat:
        description: The Personal Access Token
        type: string
        required: true

jobs:
  open-pr:
    steps:
      - name: mask token
        # Do not use ${{ github.event.inputs.pat }} directly because that would log
        # the token verbatim to the log as part of the code snippet since it has not
        # been masked before running the snippet.
        run: echo "::add-mask::$(jq -r '.inputs.pat' <$GITHUB_EVENT_PATH)"

This would be simpler, at the expense of security (the token gets passed unencrypted via GET calls) and usability (the user has to generate that PAT, and maybe store it securely somewhere to avoid having to generate new tokens all the time).

A variation on this would be a GitHub App (backed by a relative simple Azure Function, based on this toy GitHub App) which would generate the OAuth token, encrypt it using its public key and store that in a cookie (so that it can run serverless, i.e. all the state is stored in the cookie). The Azure Function would serve an "almost static" page, trigger the workflow_dispatch on the server side (so that the unencrypted token never even reaches the user's machine), wait for the run to start and then redirect to that page.

[dscho]

Let's merge this, and continue developing this new process over in this ticket, which I plan on addressing using the same workflow as I used for the mintty experiment in dscho#8 after slightly adjusting it to accept that PAT.