fix: guard ReadTarEntry against decompression bombs (OOM)

[jkutner]

Summary

• Add maxTarEntrySize constant (4 MB) to pkg/archive/archive.go
• ReadTarEntry now rejects entries whose declared header.Size exceeds the limit before reading any data
• A secondary io.LimitReader + byte-count check catches malformed archives where the header size is understated
• Two new unit tests cover both rejection paths

Motivation

A malicious or malformed buildpack image could include a tar entry (e.g. buildpack.toml / lifecycle.toml) with an arbitrarily large payload. ReadTarEntry previously called io.ReadAll with no bound, allowing a decompression bomb to exhaust heap memory. This is CVSS 3.1 score 6.5.

Test plan

• go test ./pkg/archive/... -run TestArchive/Archive/#ReadTarEntry — all 6 cases pass
• make build — binary builds cleanly
• make lint — 0 issues
• make tidy — no changes

[jkutner]

@jjbustamante can you take a look at this? It's meant to address pack OOM via decompression bomb in buildpack descriptor read, but i'm not sure if this will cause other issues.

[jjbustamante]

@jjbustamante can you take a look at this? It's meant to address pack OOM via decompression bomb in buildpack descriptor read, but i'm not sure if this will cause other issues.

I have issues with accessing the maintainers message (it is attached to my Broadcom email account) could you send me the Of Out Memory message? @jkutner