Security review: bound buildpack execution time

[natalieparellano]

Description

In the security review, this is LOW-3: Denial-of-Service (DoS) provoked by an unbound execution time. The action plan asks us to

Implement a watchdog or equivalent in order to clean the used caches and terminate the detect or build phases after a certain time threshold

Proposed solution

• pack should accept a configurable timeout for the detect and build phases
• If the detect or build phase lasts longer than the timeout, pack should stop the container, perform any necessary cleanup, and exit with error
• Necessary cleanup could include:
  • cleaning/deleting caches
  • ensuring filelocks are released (see Security review: prevent simultaneous builds of applications having the same name lifecycle#1383)
  • other stuff we haven't thought of

Describe alternatives you've considered

Additional context

Related issue: buildpacks/lifecycle#1383

• This feature should be documented somewhere

[loewenstein]

Are we sure the additional complexity is worth it? In the local dev case this should be pretty much not matter and in the CI case, the CI system should be able to easily take care of timeouts. Right?

In what use case do we see this relevant?

[natalieparellano]

@loewenstein I am basically of this opinion as well. I think this issue was more relevant went we were considering adding a file locking mechanism to prevent simultaneous builds of the same name (see buildpacks/lifecycle#1383) which would necessitate some cleanup that a time guard could handle. But, since we decided not to do that work, maybe we don't need to do this work. I am going to close this issue and then if others in the community feel differently, we could restart the discussion.