Consider running abi3audit on abi3 wheels

[hauntsaninja]

I saw this post earlier today: https://blog.trailofbits.com/2022/11/15/python-wheels-abi-abi3audit/

Seems like a thing that could be useful for cibuildwheel to run automatically, like we do for auditwheel

[hugovk]

Note the https://github.com/trailofbits/abi3audit repo says:

⚠️ This project is not ready for general-purpose use! ⚠️

[woodruffw]

Whoops, I meant to remove that 😅 -- it's still definitely a beta and there will be bugs, but I'd consider it ready for general use. I'll remove that note in the README.

[henryiii]

I think we should at least mention this in docs, that would be a good first step.

[woodruffw]

JFYI: We've dropped abi3audit's minimum Python version down to 3.8, just in case that helps with any future integration plans! I haven't made a release for those changes yet, but I'll do so in the near future.

[joerick]

Seeing as cbuildwheel is a collection of best-practice around wheel building, I'd like to integrate this. I don't think it actually fits the model of repair-wheel-command, because (correct me if I'm wrong):

• it doesn't ever change the wheel, just produces a report on stdout
• it doesn't need to be run in the build environment (e.g. the docker container), it can run wherever.
• it doesn't support the build pythons we do (we're still 3.6+), and it's 3.8+.

So I'm thinking that it doesn't need to be installed in each build environment, rather, it can be run at the end of the build once all wheels have been built.

1. We could have a command CIBW_AFTER_ALL analogous to CIBW_BEFORE_ALL, that runs in the container. The default would be a noop, unless there are abi3 wheels present, where it would be pip install abi3audit && abi3audit {abi3wheels}
2. We could run abit3audit in the host python instead. Once all containers are finished, check for abi3 wheels, if there are any, install abi3audit into a venv and check them there. This doesn't feel like an CIBW_AFTER_ALL-style command, there's not really any point for a user to run anything else at this point, since they could just run a command after cibuildwheel instead. But the user might want to disable the check (or change options?) so it might have an option like CIBW_ABI3AUDIT=enabled|disabled|custom-command --with --flags {abi3wheels}

Curious if anyone has any strong opinions/preferences on the above.

p.s. option (2) above wouldn't work on Python 3.7, which cibuildwheel still runs on. However, that EoL is only a couple months away, so it shouldn't be an issue long-term.

[woodruffw]

because (correct me if I'm wrong):

Your summary is correct! abi3audit only runs on wheel files (or specs that resolve to wheel files), and is purely introspective (i.e. it doesn't make any changes).

[henryiii]

Could we generalize (2) a bit? Have a cibuildwheel audit command & audit environment? And provide {wheels} (all wheels) and {abi3wheels} (just the ABI3 wheels)? Edit: or, maybe not, someone could just add the audit step afterwards pretty easily.

[joerick]

Yeah, we could do, I'd like it be general. But ideally, we'd only install/run abi3audit if there were any ABI3 wheels produced, I'm not sure how to generalise that logic...