Docker-based infrastructure: Allow installation of whitelisted packages in scripts not in the .travis.yml

The APT addon allows installing APT packages on all infrastructures. However, when using the container-based infrastructure, sudo is disabled during user-defined build phases like before_install. This prevents installing packages with apt-get in these phases.

A helper with special permissions (e.g. whitelisted-apt-get) could allow installing whitelisted packages in scripts instead of specifying them upfront in .travis.yml. This would make it much easier and less time-consuming to install required packages.

My build scripts need certain packages, but the specific packages can only be determined at runtime rather than defined upfront. A whitelisted APT helper would allow installing these runtime-determined packages in the scripts themselves.

How would you propose that we determine the list “at runtime”? The .travis.yml gets fetched and we process it to only compile the build script using travis-yml.

I guess one approach we could take is to parse the .travis.yml configuration file prior to the build to extract any dependencies or requirements specified for the build. By scanning this file, we can dynamically generate a list of only the packages that are actually needed for the particular build, rather than installing anything and everything that may be called for later.

Additionally, we can maintain a predefined manifest file in the repository containing approved and vetted packages that are commonly used. Any dependencies called for during the parse that are contained in this manifest could be automatically approved for installation. For less common or unapproved packages not in the manifest, we can prompt the user to confirm installation prior to adding them to the approved list.

Finally, we could leverage utilities like apt-cache to search for required packages at build time and match them against our approved repositories, avoiding the risk of pulling in unwanted software from unverified sources.

By handling dependency resolution in advance using a combination of these techniques, we can restrict the build script itself to only installing pre-confirmed packages, achieving security while still allowing for flexibility in dynamically determining dependencies from the actual build configuration.