[BUG] After upgrade to 3005.2, failure to check out branch for gitfs pillar

[anandb-ripencc]

Description
A minion is unable to access pillar data from an alternative branch in git. This was working with 3005.1, but broke after upgrade to 3005.2

Setup
CentOS 7 salt master, configured with git repos for formulas and pillar data.

Please be as specific as possible and give set-up details.

• on-prem machine
• VM (Virtualbox, KVM, etc. please specify)
• VM running on a cloud service, please be explicit and add details
• container (Kubernetes, Docker, containerd, etc. please specify)
• or a combination, please be explicit
• jails if it is FreeBSD
• classic packaging
• onedir packaging
• used bootstrap to install

Steps to Reproduce the behavior
Master config:

ext_pillar:
  - git:
    - __env__ https://gitlab/pillar-dns.git
    - master  https://gitlab/ssl-certs.git
  - gitstack:
    - master  https://gitlab/ssl-certs.git:
      - stack: stack.cfg

Create a new branch called testing in pillar-dns.git repo, and add some pillar data to it. On a minion, run salt-call pillar.data pillarenv=testing

Expected behavior
The new data should be visible in the output of the salt call on the minion.

Screenshots
Not applicable.

Versions Report

salt --versions-report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Salt Version:
          Salt: 3005.2

Dependency Versions:
          cffi: 1.14.6
      cherrypy: unknown
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: 4.0.10
     gitpython: 3.1.32
        Jinja2: 3.1.0
       libgit2: Not Installed
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: 2.21
      pycrypto: Not Installed
  pycryptodome: 3.9.8
        pygit2: Not Installed
        Python: 3.9.17 (main, Aug  4 2023, 19:59:44)
  python-gnupg: 0.4.8
        PyYAML: 6.0.1
         PyZMQ: 23.2.0
         smmap: 5.0.0
       timelib: 0.2.4
       Tornado: 4.5.3
           ZMQ: 4.3.4

System Versions:
          dist: centos 7 Core
        locale: utf-8
       machine: x86_64
       release: 3.10.0-1160.92.1.el7.x86_64
        system: Linux
       version: CentOS Linux 7 Core

Additional context
Add any other context about the problem here.

[welcome]

Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey.
Please be sure to review our Code of Conduct. Also, check out some of our community resources including:

• Community Wiki
• Salt’s Contributor Guide
• Join our Community Slack
• IRC on LiberaChat
• Salt Project YouTube channel
• Salt Project Twitch channel

There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar.
If you have additional questions, email us at [email protected]. We’re glad you’ve joined our community and look forward to doing awesome things with you!

[OrangeDog]

Did you run salt-run git_pillar.update first?

Changes won't be seen until it updates, either on a timer or manually.

[anandb-ripencc]

No I did not run salt-run git_pillar.update. I did not realise that it was a necessary step when upgrading. Is this documented in any upgrade or release notes?

[OrangeDog]

It is not a necessary step when upgrading. It is a necessary step when changing anything in your git pillar and not wanting to wait for the cache to expire.

[cmcmarrow]

@anandb-ripencc did salt-run git_pillar.update fix the problem?

[anandb-ripencc]

@OrangeDog @cmcmarrow salt-run git_pillar.update did NOT fix the problem. I still don't see why this is needed. In previous versions, I could commit to a new branch in the pillar repository, and then access that pillar data on the minion with salt-call pillar.data pillarenv=<branch>. It is broken in 3005.2 (which we need for to fix CVE-2023-20897). Is there going to be a 3005.3 release with this fix?

[OrangeDog]

In previous versions

The default update interval is 60 seconds. You may have never noticed.

[anandb-ripencc]

@OrangeDog no, I am aware that the default update interval is 60 seconds. I would commit a change, and then wait a bit, and then go apply a state or access the pillar data. This is most useful for testing new things without touching the master branch. But in this case, it doesn't matter how long I wait. The salt master just cannot fetch the specified branch.

[OrangeDog]

Yes, we've established there's a problem now. You could have been using git_pillar.update instead of waiting.

[cmcmarrow]

Hi @anandb-ripencc I believe I got a fix for you. #65017 I would appreciate it if you give it a try and/or look.

[cmcmarrow]

Closing due to it being fixed by #65017. Feel free to open another ticket if you find another gitfs issue.

[anandb-ripencc]

@cmcmarrow I see a 3006.3 release, with a fix for this bug, but there's no 3005.3 release yet. When are you going to release 3005.3?

[cmcmarrow]

@anandb-ripencc 3005.3 is coming. We wanted to get 3006.3 out first.