> This commit does not do what it says it does. All it does, in fact, is replace safe_fprint with an unsafe variant, potentially introducing another vulnerability. The code was merged without any discussion, and lives on to this day. libarchive should also be considered compromised until proven otherwise.
This is very far from the truth, from what I can tell. If you look at the PR, it does, in fact, add strerror(errno) to the end of the error line, as it claims in its description.
And the switch from safe_fprintf() to regular fprintf() for the archive_error_string matches the rest of the codebase, which is scattered with calls to lafe_errc() and lafe_warnc() with archive_error_string (forwarding to vfprintf()). If the contents of that string were considered sensitive to print out, then it would hardly be a new vulnerability. Especially compare the code in tar/write.c, which calls fprintf(stderr) to output the archive_error_string in precisely the same way as the PR in question does.
Note that safe_fprintf() has nothing at all to do with memory safety: its only purpose is to escape unprintable characters before printing them. Indeed, a stack overflow bug within the safe_fprintf() implementation was the subject of a CVE in 2022 [0].