Picking a winner: how to pick the right dependency (resolution graph)
Not currently scheduled.
Presented by
-
Eve is an engineer working on open source software security at Google. She lives in Australia, with her cat Mochi, who is surprisingly proficient at JavaScript. Between D&D campaigns, she can be found deciphering the Cargo dependency-resolution algorithm bug-for-bug, advocating for women in tech, and furthering adoption of open source standards like SLSA.
-
Josie is an engineer at Google, working on Open Source Supply Chain Security. She lives in Sydney, Australia, with her cat Polly, who remains sadly ambivalent about software security. Between badminton games, she can be found wrangling advisory data for vulnerability databases, finding useful health metrics about open source packages and giving tech-talks on the perils of dependency management.
Abstract
You think it’s hard to choose to take on a new dependency? Consider the challenges faced by your poor dependency resolver! That dependency graph you have is actually just one of potentially billions of valid graphs based on your constraints. What’s an algorithm to do? How does a resolver make a choice, and what were the choices that went into each algorithm?
This talk will cover your graph - or rather _your graphs_, ecosystem specific complexities, and other quirks of resolution algorithms. Why does your graph have cycles? Why does your production graph contain vulnerable packages when your test graph doesn’t? Why does the alpha-numeric name of dependencies influence resolution? Should you preference older, more stable versions of packages, or newer versions with bleeding edge features and bug fixes? Pinned, bundled, or vendored dependencies? Does it even matter, since your ecosystem has already made the choice for you?
You think it’s hard to choose to take on a new dependency? Consider the challenges faced by your poor dependency resolver! That dependency graph you have is actually just one of potentially billions of valid graphs based on your constraints. What’s an algorithm to do? How does a resolver make a choice, and what were the choices that went into each algorithm? This talk will cover your graph - or rather _your graphs_, ecosystem specific complexities, and other quirks of resolution algorithms. Why does your graph have cycles? Why does your production graph contain vulnerable packages when your test graph doesn’t? Why does the alpha-numeric name of dependencies influence resolution? Should you preference older, more stable versions of packages, or newer versions with bleeding edge features and bug fixes? Pinned, bundled, or vendored dependencies? Does it even matter, since your ecosystem has already made the choice for you?