1*ec63e07aSXin Li# LodePNG Sandboxed API 2*ec63e07aSXin Li 3*ec63e07aSXin LiThis library was sandboxed as part of Google's summer 2020 internship program 4*ec63e07aSXin Li([blog post](https://security.googleblog.com/2020/12/improving-open-source-security-during.html)). 5*ec63e07aSXin Li 6*ec63e07aSXin LiThis directory contains a sandbox for the 7*ec63e07aSXin Li[LodePNG](https://github.com/lvandeve/lodepng) library. 8*ec63e07aSXin Li 9*ec63e07aSXin Li## Details 10*ec63e07aSXin Li 11*ec63e07aSXin LiWith Sandboxed API, many of the library's functions can be sandboxed. However, they need the `extern "C"` keyword defined so that name mangling does not happen, which is why a patch that adds it is used. The only differences are found in the header file. An alternative to this is to define another library that wraps every needed function, specifying the required keyword. 12*ec63e07aSXin Li 13*ec63e07aSXin LiEven if many of the functions from the library can be sandboxed, there are some that are not supported (those which have `std::vector` parameters, overloaded functions etc.). If you really need these functions, a solution is to implement a custom library that wraps around these functions in order to make them compatible. 14*ec63e07aSXin Li 15*ec63e07aSXin Li## Patches 16*ec63e07aSXin Li 17*ec63e07aSXin LiIn the **patches** folder there is a patch file that adds `extern "C"` to the required functions in the header file in order to sandbox them. This patch is applied automatically during the build phase. 18*ec63e07aSXin Li 19*ec63e07aSXin Li## Build 20*ec63e07aSXin Li 21*ec63e07aSXin LiRun the following commands: 22*ec63e07aSXin Li 23*ec63e07aSXin Li`mkdir -p build && cd build` 24*ec63e07aSXin Li 25*ec63e07aSXin Li`cmake .. -G Ninja` 26*ec63e07aSXin Li 27*ec63e07aSXin Li`cmake --build .` 28*ec63e07aSXin Li 29*ec63e07aSXin Li 30*ec63e07aSXin LiThe example binary files can be found in `build/examples`. 31*ec63e07aSXin Li 32*ec63e07aSXin Li## Examples 33*ec63e07aSXin Li 34*ec63e07aSXin LiThe code found in the **examples** folder features a basic use case of the library. An image is generated, encoded into a file and then decoded to check that the values are the same. The encoding part was based on [this example](https://github.com/lvandeve/lodepng/blob/master/examples/example_encode.c) while decoding was based on [this](https://github.com/lvandeve/lodepng/blob/master/examples/example_decode.c). 35*ec63e07aSXin Li 36*ec63e07aSXin LiThis example code is structured as: 37*ec63e07aSXin Li- `main_unsandboxed.cc` - unsandboxed example 38*ec63e07aSXin Li- `main_sandboxed.cc` - sandboxed version of the example 39*ec63e07aSXin Li- `main_unit_test.cc` - tests(using [Google Test](https://github.com/google/googletest)). 40*ec63e07aSXin Li 41*ec63e07aSXin LiOn top of those files, there are other files used by all three of the examples: 42*ec63e07aSXin Li- `sandbox.h` - custom sandbox policy 43*ec63e07aSXin Li- `helpers.h` and `helpers.cc` - constants and functions used in the main files. 44*ec63e07aSXin Li 45*ec63e07aSXin LiThe executables generated from these files will create a temporary directory in the current working path. Inside that directory the two generated **png** files will be created. At the end, the directory is deleted. If those programs do not stop midway or return a failure code, then everything works fine. 46