Security

Llamafile is a great convenience by bundling the inference code with the weights. However, it offers less security to users in its current form than the use of untrusted safetensors/gguf weights + seperately downloaded (trusted) model impl. If llamafile takes off, users will be executing random executables downloaded from HF generated by random people, presenting a security hole through people including backdoored llama.cpp implementations.

What would be the best way to address these security concerns?

• Ultimately, if you bundle the inference code and weights, there is no way to verify anything (since the verifier must be bundled too..), so maybe just educating users is all one can do.
• Huggingface could check if .llamafiles are generated correctly, by introspecting the binary to see its just llama.cpp + the weights, but this would be overhead on keeping up with llama.cpp updates. It could also provide some autoconversion from gguf to llamafile, ensuring the security of the output.
• One could add norms for verifying signatures of downloaded llamafiles (e.g making the most common copy-pasted commands verify signatures against some PKI), or include a package manager, but the former allows attacks via mis-authentication and the latter via not being the "most convenient route".
• The most secure but least convenient outcome would be to have norms of llama.cpp distributed as an APE and have the .gguf downloaded seperately, replacing instances of wget huggingface.com/.../xyz.llamafile && ./xyz.llamafile with curl llamaup.com/up | bash and llamafile huggingface.com/.../xyz.gguf, like the "seperately downloaded llamafile server" example in the docs.