Change in behavior in bandit 1.6.0
We've noticed a spate of recent test failures within the 'pep8' jobs in oslo recently. It seems these are because of the release of bandit 1.6.0. The root cause is that the '-x' (exclude) option seems to have changed behavior. Previously, to match a path like 'oslo_log/tests/*', you could state '-x test'. This option now expects a glob patterns, such as '-x oslo_log/tests/*'. If you use bandit, you probably have to update your 'tox.ini' accordingly. See [1] for an example. It's worth noting that bandit is one of the few packages we don't manage the version for [2], so if you're not already limiting yourself to a version, perhaps it would be a good idea to do so to avoid stable branches breaking periodically. Also, this is something that really shouldn't have happened in a minor version (backwards incompatible behavior change, yo) but it has so we'll live with it. I would ask though that the bandit maintainers, whoever ye be, be more careful about this kind of stuff in the future. Thanks :) Stephen [1] https://review.opendev.org/#/c/658249/ [2] https://github.com/openstack/requirements/blob/master/blacklist.txt
On Fri, May 10, 2019 at 5:48 AM Stephen Finucane <sfinucan@redhat.com> wrote:
We've noticed a spate of recent test failures within the 'pep8' jobs in oslo recently. It seems these are because of the release of bandit 1.6.0. The root cause is that the '-x' (exclude) option seems to have changed behavior. Previously, to match a path like 'oslo_log/tests/*', you could state '-x test'. This option now expects a glob patterns, such as '-x oslo_log/tests/*'. If you use bandit, you probably have to update your 'tox.ini' accordingly. See [1] for an example.
As a note, it looks like you have to catch every .py file in this glob, so this won't work for more complex directory layouts. e.g. in Keystone, `-x keystone/tests/*` still fails, as does `-x keystone/tests/**/*`, etc. I've just blacklisted this version there.[3]
It's worth noting that bandit is one of the few packages we don't manage the version for [2], so if you're not already limiting yourself to a version, perhaps it would be a good idea to do so to avoid stable branches breaking periodically. Also, this is something that really shouldn't have happened in a minor version (backwards incompatible behavior change, yo) but it has so we'll live with it. I would ask though that the bandit maintainers, whoever ye be, be more careful about this kind of stuff in the future. Thanks :)
FWIW, looks like this was an unintentional regression[4] that they're working on fixing[5] in 1.6.1.
Stephen
[1] https://review.opendev.org/#/c/658249/ [2] https://github.com/openstack/requirements/blob/master/blacklist.txt
// jim [3] https://review.opendev.org/#/c/658107/ [4] https://github.com/PyCQA/bandit/issues/488 [5] https://github.com/PyCQA/bandit/pull/489
On Fri, 2019-05-10 at 09:07 -0400, Jim Rollenhagen wrote:
On Fri, May 10, 2019 at 5:48 AM Stephen Finucane <sfinucan@redhat.com> wrote:
We've noticed a spate of recent test failures within the 'pep8' jobs in oslo recently. It seems these are because of the release of bandit 1.6.0. The root cause is that the '-x' (exclude) option seems to have changed behavior. Previously, to match a path like 'oslo_log/tests/*', you could state '-x test'. This option now expects a glob patterns, such as '-x oslo_log/tests/*'. If you use bandit, you probably have to update your 'tox.ini' accordingly. See [1] for an example.
As a note, it looks like you have to catch every .py file in this glob, so this won't work for more complex directory layouts. e.g. in Keystone, `-x keystone/tests/*` still fails, as does `-x keystone/tests/**/*`, etc. I've just blacklisted this version there.[3]
It's worth noting that bandit is one of the few packages we don't manage the version for [2], so if you're not already limiting yourself to a version, perhaps it would be a good idea to do so to avoid stable branches breaking periodically. Also, this is something that really shouldn't have happened in a minor version (backwards incompatible behavior change, yo) but it has so we'll live with it. I would ask though that the bandit maintainers, whoever ye be, be more careful about this kind of stuff in the future. Thanks :)
FWIW, looks like this was an unintentional regression[4] that they're working on fixing[5] in 1.6.1.
Yay! Go bandit devs :) Stephen
Stephen
[1] https://review.opendev.org/#/c/658249/ [2] https://github.com/openstack/requirements/blob/master/blacklist.txt
// jim
[3] https://review.opendev.org/#/c/658107/ [4] https://github.com/PyCQA/bandit/issues/488 [5] https://github.com/PyCQA/bandit/pull/489
participants (2)
-
Jim Rollenhagen
-
Stephen Finucane