False warning about Views Bulk Operations (VBO) security update

I second this. The previous version is just fine!

This is both a simple issue and really complex. I will ultimately leave it up to Graber to re-enable it or not, as he may have had reasons for it.

I've done the same and asked maintainers to re-enable versions (that I am on) for the sake of the implicit security issue of an unsupported version. Here is a long thread on the matter here: https://drupal.slack.com/archives/CJ93UNJP4/p1663006787389719

Basically, the d.o. project page can treat minors as majors (historical reasons). Even though we might be using semver and supporting 4.x. The drupal core update status will think it's unsupported when it's not shown up here. This might be worth trying to solve in core... but I took the stance earlier this year to disable the emails and replaced it all with a little cron job that did `composer audit` and email me on results.

Here is that script if anybody wants a better workaround (catches dependencies too):

#!/bin/bash

# Pull the latest changes and run a Composer audit.
# Exit code meanings:
# - 0: No vulnerabilities found.
# - 1: Vulnerabilities detected.
# - 2: Errors occurred (e.g., missing lock file, configuration issues).
/usr/bin/find /PATH/TO/ALL/YOUR/SITES/ -mindepth 1 -maxdepth 2 -name '.git' -type d -execdir sh -c '
    # Reduce HTTP concurrency to avoid transient Packagist timeouts.
    export COMPOSER_MAX_PARALLEL_HTTP=${COMPOSER_MAX_PARALLEL_HTTP:-2}
    git pull -q
    # Only run in repos that actually use Composer.
    [ -f composer.json ] || exit 0
    audit_output=$(composer audit --locked --no-interaction --no-dev 2>&1)
    result=$?
    case "$result" in
      0) ;; # No vulnerabilities found.
      1)
        echo "$(pwd):"
        echo "$audit_output"
        ;;
      2) ;; # network timeout: skip silently to avoid cron mail
      *)
        echo "$(pwd): unexpected exit code $result"
        echo "$audit_output"
        ;;
    esac
' \;

Set it on a cron with an email and voila, low-rent checks.

Hmm, I don’t expect any issues on the old branch so I guess we can mark it as supported again but.. the fact is that it’s not supported anymore. I will not handle issues on that branch as it makes no sense and I don’t have time for that - the new one is compatible and people can just upgrade according to release docs.

@graber: ressa probably does the best explaining on this matter, but the fact is that Drupal makes me think there is a security issue and that I have to upgrade asap. This is of course not the case. The previous version is just fine and poses no threat. Yes, you're not going to support the old version and people can upgrade to the new version without any problems. But no, it is not needed to do this asap. I normally upgrade my sites once a month UNLESS there is a security issue. Now I feel forced to take action.

Marked 4.3.4 as supported then. It's not supported though and I hope everyone will be aware of that. Somehow.

@graber: Thanks!

@ressa I know and am very grateful for their work. This is definitely not a module maintainers 'fault', the issue is with Drupal itself.

The bottom of the project page has a lot of information on Drupal 7. That could probably be removed, and there could be a note saying that only the latest minor version is properly "supported" though x last minor versions will be marked as supported so people can update at their leisure. Not that everyone will read it, but that could also be in the release notes (which I do think more people that already have the module will read, though obviously not all).

@erutan good idea, I removed the D7 stuff and replaced it with

Note: While multiple 4.x minor branches are published and marked supported, only the latest minor release is actively maintained. Older minor versions remain available as to mitigate update status "unsupported" warnings but will not receive updates or fixes.

@ressa You summarized the problems really well in #5. The Slack thread is quite long, and I’m not sure everyone involved would want me to re-post it all. Thanks for turning my script into a docs page — that’s very kind of you! I will poke over there and have a look.

I think the core issue is infrastructure-related, but I’m hesitant to dig into that right now since the ongoing GitLab migration might address these problems anyway. Once we see how Drupal core interacts with those changes, that’ll be the right time to revisit.

I thought the Slack channels were public in some kind of archive system someplace... but my memory has failed me as I can't find that, so... yeah it's a "walled garden". And yeah, we won't solve that here. I miss IRC... but it had it's own challenges, they all do... sigh 😮‍💨