[210] [HIGH] Numbers that start with '0' should always be encapsulated in quotation marks - False positive in latest release 0.9.0

[ggiesen]

Describe the bug
I have the following state:

file_/etc/cron.d/certbot:
  file.managed:
    - name: /etc/cron.d/certbot
    - source: salt://files/systems/crontab.j2
    - user: root
    - group: root
    - mode: '0644'
    - template: jinja
    - context:
        mailto: user@example.com
        cron_tz: UTC
        random_delay: 60
        entries:
          - datetimespec: '0 */6 * * *'
            user: root
            command: 'certbot renew -n && cp -fp /etc/letsencrypt/live/{{ salt['grains.get']('fqdn') }}/fullchain.pem /etc/pki/tls/certs/{{ salt['grains.get']('fqdn') }}.pem && cat /etc/letsencrypt/live/{{ salt['grains.get']('fqdn') }}/privkey.pem >> /etc/pki/tls/certs/{{ salt['grains.get']('fqdn') }}.pem && chmod 0640 /etc/pki/tls/certs/{{ salt['grains.get']('fqdn') }}.pem && systemctl reload nginx; systemctl reload haproxy; systemctl restart duoauthproxy'
    - require:
        - file_exists_/etc/letsencrypt/renewal/{{ salt['grains.get']('fqdn') }}.conf

that was previously passing linting, but is now complaining about:

chmod 0640 even though the whole string is encapsulated in quotes:

[210] [HIGH] Numbers that start with '0' should always be encapsulated in quotation marks

To Reproduce
Steps to reproduce the behavior:

1. Create state above in SLS file
   2.Run salt-lint to lint it

Expected behavior
File to pass linting

Desktop (please complete the following information):

• OS: AlmaLinux 8.7
• Version 0.9.0

[ggiesen]

Looks like it was this commit that caused the issue:

cc6e617

[jcjones]

I'm also seeing this in a yaml heredoc, as:

[210] [HIGH] Numbers that start with '0' should always be encapsulated in quotation marks
./salt/prod/storage/config.sls:36
        [0:0:0:1]    mediumx QUANTUM  UHDL             0096  /dev/sch0  /dev/sg4

[210] [HIGH] Numbers that start with '0' should always be encapsulated in quotation marks
./salt/prod/storage/config.sls:38
        [0:0:1:1]    mediumx QUANTUM  UHDL             0096  /dev/sch1  /dev/sg6

fake-scsi:
  file.managed:
    - name: /usr/local/scsi.txt
    - user: root
    - group: root
    - mode: '0644'
    - contents: |
        [0:0:0:0]    tape    IBM      ULTRIUM-HH8      MA71  /dev/st0   /dev/sg3
        [0:0:0:1]    mediumx QUANTUM  UHDL             0096  /dev/sch0  /dev/sg4
        [0:0:1:0]    tape    IBM      ULTRIUM-HH6      KAJ9  /dev/st1   /dev/sg5

[jbouter]

Hi all 👋🏻 !

Thanks for the reports. We are indeed experiencing this ourselves as well. I will discuss with @roaldnefs next week and, by the looks of things, most likely remove the rule and draft a new release.

We apologise for the inconvenience caused by this.

[jbouter]

Hi @nicholasmhughes - I'd like to inform you that your change has caused a lot of false-positives, and we will therefore be reverting it to resolve that issue. I'm aware that your change was a fix for another false-positive, which we will need to address in a future release.

[nicholasmhughes]

Make sure all of these are captured in the test cases. Tests ran clean with my change.

[jbouter]

@nicholasmhughes Indeed, for the next test we will add the common false-positives. :-)

[jbouter]

This issue has been resolved in release v0.9.1