BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//programme.europython.eu//europython-2026//speaker//3RGAH
 L
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-europython-2026-UY9UAG@programme.europython.eu
DTSTART;TZID=CET:20260716T155000
DTEND;TZID=CET:20260716T162000
DESCRIPTION:Package manifests like `pyproject.toml` record source-level dep
 endencies: _pandas_ depends on _numpy_'s code. The story is different for 
 binary dependencies\, which exist whenever compiled code\, like C code\, i
 s called from Python. _numpy_ depends on _OpenBLAS_'s binaries\, but this 
 dependency relationship is not recorded anywhere. This makes _OpenBLAS_ a 
 _[phantom](https://www.endorlabs.com/learn/dependency-resolution-in-python
 -beware-the-phantom-dependency) binary dependency_.\n\nPhantom dependencie
 s are therefore hidden from programmers and researchers\, which is bad for
  at least two reasons.\n\nFirst\, security. If one of your binary dependen
 cies has a vulnerability\, this means your project is probably also vulner
 able — but you won't reliably find out about this\, since your dependenc
 y is invisible.\n\nSecondly\, sustainability. If we can't keep track of ou
 r binary dependencies\, we can't keep track of their maintainers either\, 
 which means we can't credit and [financially support](https://opensourcepl
 edge.com/) them. This can lead to [maintainer burnout](https://opensourcep
 ledge.com/blog/burnout-in-open-source-a-structural-problem-we-can-fix-toge
 ther/)\, which has already created serious supply chain issues.\n\nPython 
 is not only tremendously popular\, but also valued for its ability to easi
 ly interface with compiled libraries. According to my research\, around 20
 % of Python packages have binary dependencies.\n\nThis means that the prob
 lem of phantom binary dependencies is widespread\, and puts the public at 
 risk of harm\, eg if critical infrastructure like hospitals or transportat
 ion is compromised by exploiting the aforementioned weaknesses.\n\nI aim t
 o describe how the problem of phantom binary dependencies can be fixed wit
 hin the Python ecosystem\, and demo some of my preliminary work.\n\nFirst\
 , binary dependencies must be identified. Tools like _[auditwheel](https:/
 /github.com/pypa/auditwheel/)_ and _[elfdeps](https://github.com/python-wh
 eel-build/elfdeps/)_ are able to identify a project's [required dynamic li
 braries](https://vlad.website/how-binary-dependencies-work/). If we create
  better APIs for these tools\, and integrate them with package managers su
 ch as _pip_ and _uv_\, we can give developers and researchers visibility i
 nto binary dependencies\, dispelling the phantom.\n\nBeyond this\, standar
 ds like [PEP 725](https://peps.python.org/pep-0725/)\, [PEP 770](https://p
 eps.python.org/pep-0770/) and [PEP 804](https://peps.python.org/pep-0804/)
  specify how we might record binary dependency relationships in an easily 
 accessible way. I'll explain how we can build on these standards to create
  tools that will allow users and researchers to explore binary dependencie
 s and identify security issues by default.\n\nLastly\, I want to talk abou
 t the road towards the ultimate aim of having binary dependencies be manag
 ed not by Python package managers\, but by system package managers\, as th
 ey should be. This will require interoperation between package managers\, 
 and I'll explain how this might work.
DTSTAMP:20260524T121644Z
LOCATION:Theatre Hall (S2)
SUMMARY:Binary Dependencies: Identifying the Hidden Packages We All Depend 
 On - Vlad-Stefan Harbuz
URL:https://programme.europython.eu/europython-2026/talk/UY9UAG/
END:VEVENT
END:VCALENDAR