docs(website): remove references of tj-actions

[orhun]

There is some drama surrounding the tj-actions organization on GitHub and I am removing their git-cliff action from the documentation until this is resolved: tj-actions/git-cliff#74

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 41.47%. Comparing base (bf50336) to head (40b403e).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1097   +/-   ##
=======================================
  Coverage   41.47%   41.47%           
=======================================
  Files          21       21           
  Lines        1811     1811           
=======================================
  Hits          751      751           
  Misses       1060     1060           

Flag	Coverage Δ
unit-tests	41.47% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[alerque]

Seems smart. I have several project affected by secrets exfiltrated by his changed-files action. Having reviewed the current situation I think it's probably fair to note:

• The immediate compromise effects seems to be reversed. The hijacked tags are reset and bad commit removed.
• The root cause has not been found, and the claims don't quite add up. The claim is that a PAT token was somehow compromised fro a bot account, but either the PAT had permissions on the non-bot account as well or there is more to this story, because at least one bad push happened from the actual account, not the bot.
• How the PAT was compromised is either not known or not disclosed. Almost certainly this means personal infrastructure (laptop? backups? shell history? bad bastebin? who knows...) was compromised, meaning the OP did not have good personal security practices and may be still compromised.
• Their post-mortem says nothing about personal security measures taken. Was 2FA added to their account? Did they change their personal password? Do they use a password manager? No mention at all of
• The commit history for the project is littered with bot commits and evident rubber stamping of dependency updates and such. Auditing the history suggests they don't know or care a lot about transparency or expect people to actually check up on things. 45 major versions (not to mention lots of minor/patch versions) do not actually indicate that much API breakage, many of the major bumps are just for dependency churn. This at least partially contributed to downstream projects rubber stamping version updates and accepting the eventual compromise without investigation.
• The upstream issues about the compromise have been locked as "too heated" when nothing particularly heated was even there, and without answering relevant post-mortem questions about account security.

Overall even if there isn't a currently active attack in progress I think not trusting this actor's work without verifying and pinning and not broadly recommending their actions for use is probably a good idea until they demonstrate some better practices and more actual transparency.

[orhun]

Exactly. Good points.

I should also check the other 3rd party GitHub actions at some point and verify that they are following good security practices.

[jackton1]

Seems smart. I have several project affected by secrets exfiltrated by his changed-files action. Having reviewed the current situation I think it's probably fair to note:

• The immediate compromise effects seems to be reversed. The hijacked tags are reset and bad commit removed.
• The root cause has not been found, and the claims don't quite add up. The claim is that a PAT token was somehow compromised fro a bot account, but either the PAT had permissions on the non-bot account as well or there is more to this story, because at least one bad push happened from the actual account, not the bot.
• How the PAT was compromised is either not known or not disclosed. Almost certainly this means personal infrastructure (laptop? backups? shell history? bad bastebin? who knows...) was compromised, meaning the OP did not have good personal security practices and may be still compromised.
• Their post-mortem says nothing about personal security measures taken. Was 2FA added to their account? Did they change their personal password? Do they use a password manager? No mention at all of
• The commit history for the project is littered with bot commits and evident rubber stamping of dependency updates and such. Auditing the history suggests they don't know or care a lot about transparency or expect people to actually check up on things. 45 major versions (not to mention lots of minor/patch versions) do not actually indicate that much API breakage, many of the major bumps are just for dependency churn. This at least partially contributed to downstream projects rubber stamping version updates and accepting the eventual compromise without investigation.
• The upstream issues about the compromise have been locked as "too heated" when nothing particularly heated was even there, and without answering relevant post-mortem questions about account security.

Overall even if there isn't a currently active attack in progress I think not trusting this actor's work without verifying and pinning and not broadly recommending their actions for use is probably a good idea until they demonstrate some better practices and more actual transparency.

A more productive approach here would be to contribute to the project. Security attacks are very common in software, and trusting the project or its owner without concrete suggestions for improvements does nothing to enhance the quality of the project. Oddly, this issue isn’t a reflection of poor security practices; rather, it highlights the resources available to open-source developers, both financially and in terms of community support.

[jackton1]

@orhun This same attack also hit reviewdog/reviewdog#2079.

[orhun]

Good to know @jackton1 - I just checked and none of my repos use actions from that organization, so we should be safe, I hope :D