Even if you were sure it couldn’t, you couldn’t guarantee that a future version of identify wouldn’t be able to do so, due to a bug.
Lot’s of big security breaches happen by combining several minor overlooked things in a code base, therefore a developer should always strive to write defensive code, therefore I would never ask an external command to verify an image file that I am not sure to be really an image. But that’s me 
I’m working on the file validation for the library right now. Hope I would finish it soon.
You can use System.cmd("file", ["--mime", "--brief", filepath]) call to get mime type for the file and include it inside the validation function.
We have the elixir-plug/mime library if you want to refer to extension directly instead of mime type of the file (you can use it to get mime types by extension).
This only maps mime type, doesn’t validate them, and using external tools from the OS to do validations always open my eyebrows… I really don’t like libraries that rely on it. But that’s me… maybe because I work in the security space.
What approach would you recommend to implement? Do you have any concerns about the file linux library?
As I said I just have concerns about using calls to the OS, because this will open new scopes of vulnerabilities, like path expansion to undesired locations in the event of a bug.
So if things can be checked from within the programming language without using OS tooling then I will go with it, but If is not really possible to implement it in Elixir, then you really need to resort to external tools.
I am not at all an expert in images manipulation and verification, but I am almost sure to have seen in the past binary matches being used to check for the file mime type, but don’t recall where it was.
Found the library Group4Layers/ex_image_info
The code for png:
defmodule ExImageInfo.Types.PNG do
@moduledoc false
@behaviour ExImageInfo.Detector
@mime "image/png"
@ftype "PNG"
@signature <<"PNG\r\n", 0x1A, "\n">>
@signature_ihdr <<"IHDR">>
## Public API
def seems?(<< _::bytes-size(1), @signature, _rest::binary >>), do: true
def seems?(_), do: false
def info(<< _::bytes-size(1), @signature, _::size(32), @signature_ihdr, width::size(32), height::size(32), _rest::binary >>), do: {@mime, width, height, @ftype}
def info(_), do: nil
def type(<< _::size(8), @signature, _::size(32), @signature_ihdr, _rest::binary >>), do: {@mime, @ftype}
def type(_), do: nil
end
Not sure if this is the most secure way of validating them or not… As I said I am not an expert on the matter.
You can always integrate with an Erlang NIF to a C library that uses ImageMagick’s code (I believe in Linux it’s called libmagick?) or a Elixir<=>Rust bridge (namely rustler) to a Rust library that does [almost] the same. It’s more complex and you’re still at the mercy of native code’s capriciousness but it’s less brittle than calling external programs at least (although that can also be debatable depending on OS and library versions).
If your assumption is that the software that verifies that file format can be buggy, then there is no software that verifies the file format that would be surely bug free, therefore there is no way to verify the file format itself.
This is an external software, thus opens a new scope of vulnerabilities. As a developer you may not be familiar with all the ways hackers find to chain the most innocent approaches developers use for convenience when solving their problems, but anyone in the infosec community can tell you a lot of stories around chaining mistakes and assumptions made by developers. I am in the security space only for 2 years as a developer advocate, not as a security researcher, and I already seen enough to realise how our software industry is broken for how they approach software development… Bear in mind that I am not accusing anyone in specific here, it’s just the reality where we leave, and that unfortunately isn’t changing quickly enough, as per data-breaches growing month by month indicate.
I am aware of the issues by invoking a third party tool but what are the alternatives? Implementing your own solution in Erlang/Elixir may actually be less secure, as you can make mistakes and introduce bugs that have been addressed in more battle-tested solutions. Integrating a C-library brings other concerns. They all have trade-offs.
Not necessarily less secure if done by a subject matter expert that does his own research and see how that OS libraries have implemented the check and port it then to Elixir.
Calling OS software should be the last resort in my opinion.