Replies: 1 comment 2 replies
-
Anyone? I might try playing with a fork of twine to trim dependencies. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The recent Ultralytics incident had me thinking about supply chain attacks. Twine obviously needs to have access to upload credentials, but at present it can only be installed with quite a lot of dependencies. If any of these were compromised, they could get into environments where twine is used to upload other packages, and potentially upload malicious versions of those. This is somewhat mitigated by the recommended Github action pinning all dependency versions, but that's probably not bulletproof, and it doesn't help projects not using that (e.g. on Gitlab).
I've included the log (installing from current
main
branch) below , but I think there are 3 main groups:.pypirc
file. But this was stated 3 years ago (Keyring as an extra_requires? #837), and since then it's increasingly common and encouraged to upload from CI platforms, while it's less convenient to upload locally. CI platforms generally offer ways of accessing a secret which don't need keyring.twine check
. We only actually want to check that rst is valid, but doing that pulls in a syntax-highlighting library and a compiled HTML sanitiser. It also can't check Markdown without an extra dependency (cmarkgfm
).(I'm not describing the dependencies which seem more or less essential, like requests)
Is it worth trying to do trim this down a bit? We could either try to find/make alternatives to the direct dependencies which have fewer transitive dependencies, move some functionality to optional dependencies, or split out a core upload package which could be used directly on CI platforms, while keeping
twine
for uploading from a local build. 🤷Installation log
Beta Was this translation helpful? Give feedback.
All reactions