ansible-lint v5 now requires ansible?

[srl295]

as of ansible/ansible-lint#1316 (merged yesterday?) version https://github.com/ansible-community/ansible-lint/releases/tag/v5.0.0 ( released 3 hours ago) it seems that ansible-lint now requires ansible to be installed ( see release notes under the v5.0.0 tag)

This completely breaks ansible-lint-action.

Traceback (most recent call last):
31
  File "/usr/local/bin/ansible-lint", line 5, in <module>
32
    from ansiblelint.__main__ import _run_cli_entrypoint
33
  File "/usr/local/lib/python3.8/site-packages/ansiblelint/__main__.py", line 34, in <module>
34
    from ansiblelint import cli
35
  File "/usr/local/lib/python3.8/site-packages/ansiblelint/cli.py", line 18, in <module>
36
    from ansiblelint.file_utils import expand_path_vars
37
  File "/usr/local/lib/python3.8/site-packages/ansiblelint/file_utils.py", line 14, in <module>
38
    from ansiblelint.config import options
39
  File "/usr/local/lib/python3.8/site-packages/ansiblelint/config.py", line 103, in <module>
40
    if ansible_collections_path() in os.environ:
41
  File "/usr/local/lib/python3.8/site-packages/ansiblelint/config.py", line 71, in ansible_collections_path
42
    if ansible_version() >= ansible_version("2.10.0.dev0"):
43
  File "/usr/local/lib/python3.8/site-packages/ansiblelint/config.py", line 85, in ansible_version
44
    proc = subprocess.run(
45
  File "/usr/local/lib/python3.8/subprocess.py", line 489, in run
46
    with Popen(*popenargs, **kwargs) as process:
47
  File "/usr/local/lib/python3.8/subprocess.py", line 854, in __init__
48
    self._execute_child(args, executable, preexec_fn, close_fds,
49
  File "/usr/local/lib/python3.8/subprocess.py", line 1702, in _execute_child
50
    raise child_exception_type(errno_num, err_msg, err_filename)
51
FileNotFoundError: [Errno 2] No such file or directory: 'ansible'
Lint Markdown
0s
Lint GitHub Actions

Might be good enough to somehow change the Dockerfile to pip install a pre-5.0 version of ansible-lint for now… Or just add ansible to the Dockerfile.

However, in general, it seems like it's not a good idea to just include the 'latest' ansible-lint without any restriction, because breakage like this will happen. We saw build failures from 3 hours ago when 5.0 of ansible-lint dropped.

[srl295]

also if there was a prebuilt ansible-lint-action ( #36 ) this would have been mitigated I suppose, because the prebuilt image would be used instead of using the latest every time.

[srl295]

Ref: https://unicode-org.atlassian.net/browse/CLDR-14483

[webknjaz]

Thanks for the report! The workaround could be using with: override-deps: ... for now.

[srl295]

@webknjaz Hm, not sure how that would work. I made a PR #46 …

[webknjaz]

Merged. If you look at the README, it already has this example:

    - name: Lint Ansible Playbook
      uses: ansible/ansible-lint-action@master
      with:
        override-deps: |
          ansible==2.9
          ansible-lint==4.2.0

[srl295]

@webknjaz I was just trying that when I saw you merged.

hey, would you consider tagging a release of ansible-lint-action ? (thanks for this action!)

[srl295]

i see other actions (checkout, etc) make a v1, v2 branch etc . so you can use ansible-lint-action@v2 to get the major version, and then tag v2.0.1 etc.

But just a numeric tag would be fine too so i dont have to include a specific commit

[srl295]

OK this is working for me:

    - name: Lint Ansible Playbook
      uses: ansible/ansible-lint-action@c37fb7b4bda2c8cb18f4942716bae9f11b0dc9bc

[webknjaz]

i see other actions (checkout, etc) make a v1, v2 branch etc . so you can use ansible-lint-action@v2 to get the major version, and then tag v2.0.1 etc.

The security considerations of versioning are virtually unsolved in the GitHub Actions ecosystem. GitHub showcases and promotes bad practices in this regard, unfortunately. I recommend that you, as a user, not trust any tag-based or branch-based versioning in GHA and always use commit SHA. Of course, you may rely on some trusted repos like the ones GitHub maintains but nothing else. People tend to forget that tags are floating pointers to an arbitrary repo revision just as much as branches. And the end-users who rely on things like @v1 are just as responsible for this decision as GitHub that advertises it. Most folks don't understand how Git works, don't understand security, or the consequences just don't occur to them because of the lack of experience.

To make it a bit more illustrative:

1. You start using some/action@v1 which points at commit XXX.
2. It v1 gets updated to point to XXX1 (for v1.1).
3. You keep using it, you get new cool features.
4. A malicious actor Bob with access to that action (a maintainer even) adds a commit YYY that has some malware and points v1 at YYY.
5. The action keeps working, no features broken. With just a tiny difference that it steals something from you (accessing secrets) or modifies your artifacts (supply chain attack).
6. Shortly after (4), Bob reverts it and points v1 to the next legitimate version v1.2 at commit XXX2
7. You keep using it and don't have any suspicion that you were compromised or maybe worse.
8. There are no logs or any other protection against this whatsoever. There's almost no trace in the system and no tooling to track such breaches. The log will just say that GHA checked out v1 and that's it! (Well, I guess if you know upfront that you're going to be attacked, then you'd enable debug mode in GHA and maybe it'd contain the real commit hash that got used but you're informed about this by hackers)
9. After some time, job logs expire and you lose any chance to notice if things went wrong (given that at least anything suspicious ends up in that log).

Now, I understand that we're on the maintenance side of the problem but nevertheless, I think it's wrong to support GH in spreading these unsecured practices. This is why I'm still looking into a more sustainable solution.

Another problem is that tags are supposed to be immutable but there's nothing in Git enforcing this so GitHub basically abuses the original purpose of tags by keeping to force-push them. This is something that contributes against traceability as demonstrated above.

I'm looking for better solutions in another project that would at least keep the tags immutable on our side (pypa/gh-action-pypi-publish#45). That's why I ended up postponing tagging things...

[srl295]

@webknjaz fair enough… 

[ssbarnea]

Closing as we already have v6 on main and soon also add a tag for it.