Change to compile jemalloc from source

[gaffneyc]

As brought up in #27 there are possible supply chain attacks against
anyone using this buildpack. The main concern is that a compromised
binary could be uploaded and there is no way to check that the hosted
binaries are trusted. Going a level deeper there is no way to verify
that the compiled binaries I've uploaded can be trusted (I promise
they're fine!).

This goes a step farther and removes one more random dude on the
Internet (me!) from the chain of trust. By compiling from source and
posting known checksums of those sources it is possible to verify
exactly what is being built and to be notified if the source changes.
This has the added benefit of not needing to provide binaries for each
new release of Jemalloc or launch of a new Heroku stack. Builds are now
cached per version and stack so that changing either will cause a
rebuild on the first deploy.

[gaffneyc]

Was able to remove the cached check by including the stack in the cache path. This could lead to bloat in the cache but I don't know at what point that becomes an issue.

TODO

• Test on Heroku
• Document how to clear cached builds
• Decide what to do if the checksum is not in the list (e.g. new version comes out but the buildpack hasn't been updated)

[rofreg]

🙌 This looks really fantastic! I'll close #27 in favor of this PR.

Two quick notes in case they're helpful:

• Heroku's latest documentation on clearing the build cache is here, if you'd like to just link to it from your README.
• If you're concerned about cache bloat, it might make sense to add a clean step in addition to download and compile, which could delete all contents of $CACHE_DIR/jemalloc other than $STACK/$version. I believe that would solve the cache bloat problem, by automatically clearing old cached binaries when the stack or version changes.

[gaffneyc]

Finally had a chance to deploy it to an app on Heroku today and looks like it's working great. A fresh build takes a minute or two but only happens once per stack and version.

If you're concerned about cache bloat, it might make sense to add a clean step in addition to download and compile, which could delete all contents of $CACHE_DIR/jemalloc other than $STACK/$version.

That's a good idea. My original thought was it would make it easier to implement #12 but only the current version is copied into the slug and the buildpack doesn't have access to the build cache at run time. It would make it faster to revert to an older version with a deploy though.

[pirj]

Is it possible to override this somehow? Via Heroku env vars?
Maybe it would be possible to supply a checksum there, too?

[gaffneyc]

Yep, you can override it by setting JEMALLOC_CHECKSUM

https://github.com/gaffneyc/heroku-buildpack-jemalloc/pull/28/files#diff-a64a7d9b82578ca3053416d56631a61e0ceabed87619415663030e3842429e05R55

[pirj]

Decide what to do if the checksum is not in the list (e.g. new version comes out but the buildpack hasn't been updated)

Maybe use the latest jemalloc tag that the buildpack is aware of? There's a default version anyway:

version="5.2.1"

And warn during the build that a new version is available (but who looks at the logs anyway) to update the buildpack?

BTW, 5.3 may be released sometimes soon 🎉

[gaffneyc]

Decide what to do if the checksum is not in the list (e.g. new version comes out but the buildpack hasn't been updated)

I think we can fail the build if JEMALLOC_VERSION isn't in the checksum list and JEMALLOC_CHECKSUM isn't set. Since an operator is changing the configuration to specify a version of jemalloc to use I think failing the build wouldn't be that surprising since they've now created a configuration problem.

[gaffneyc]

Haven't had a chance to circle back on this but we've been using it for months in production. With the heroku-22 stack becoming generally available I'm planning to test a stack upgrade then come back and get this finished and merged. I've cut builds for heroku-22 in the mean time.