Wrong package for bz2

[oxfordpelican]

zephyr/scripts/requirements-run-test.txt

Line 19 in 74c5c84

bz

This package is not the right package for bz2 support and should be removed.

[github-actions]

Hi @oxfordpelican! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[stephanosio]

bz is indeed a wrong package -- the package only contains a.py with print("aa") and seems harmless at this time. Nevertheless, we need to get rid of this ASAP as a preventative measure against malicious future updates.

Note that v3.7.0 is also affected by this and needs to be fixed.

cc @zephyrproject-rtos/security

[golowanow]

bz is indeed a wrong package -- the package only contains a.py with print("aa") and seems harmless at this time. Nevertheless, we need to get rid of this ASAP as a preventative measure against malicious future updates.

i think the issue deserves higher priority than 'medium': the package is propagated already on every host where requirements-run-test were applied making them vulnerable for updates, isn't it ?

[stephanosio]

the package is propagated already on every host where requirements-run-test were applied

That is correct.

making them vulnerable for updates, isn't it ?

In theory, yes; though, at first glance, the package looks to be only an artifact of someone testing package publishing and the author does not seem to have any malicious intent.

i think the issue deserves higher priority than 'medium':

Maybe. I defer to @zephyrproject-rtos/security on this.

[golowanow]

the package looks to be only an artifact of someone testing package publishing

personally I'm paranoid looking on that as a supply chain attack sleeping seed.

also It would be nice to see maintainers assigned for all ./scripts/requirements*.

[stephanosio]

personally I'm paranoid looking on that as a supply chain attack sleeping seed.

Technically speaking, we are currently wide open to Python package supply chain attacks because we do not "version lock" the packages or record/verify the package hashes, as do other more complete package management solutions (e.g. npm).

If we are really paranoid, we probably should look into using add-ons like Pipenv or pip-tools that provide these capabilities.