Back to sources: what's in your binary?
Tracing back from a binary to its corresponding source code
- Track: Legal and Policy Issues devroom
- Room: H.1301 (Cornil)
- Day: Sunday
- Start: 09:00
- End: 09:25
Software is (often) distributed as binary. But where is the corresponding source code? Given a binary, how can you find out which source code was used to compile?
Using advanced techniques and open source tools, we can find out which source code was built in a binary. The applications are important for FOSS license compliance and/or enforcement as well as general code hygiene and build sanity.
Can you tell exactly which files are baked into the binaries of the software you build and distribute?
There are many applications for this knowledge:
- facts finding for FOSS license compliance and enforcement.
- better control of what third-party code you use and depend on and their related FOSS license requirements.
- general software and build hygiene such as pruning obsolete or dead code.
With clarity on what's in your binary, you can better understand:
- if a file is really used or not and what it is used for.
- if and how files are linked together such as static vs. dynamic linking.
- if some extra files are pulled from network repositories at build time.
- what are your build and runtime dependencies.
We will review why this does matter, present available FOSS tools and techniques to get back to the corresponding sources from built binaries using dynamic build tracing and static analysis; and the applications, usage and caveats of these techniques for various programming languages and platforms.
So join me and let's find out what's in your binary!?
Speakers
 |
Philippe Ombredanne |