True, the logging is part of the library, but it’s totally centered on what the developers are logging. It’s a bad practice to log sensitive information, which can be used by someone with access to the logs for sure, but that doesn’t mean the library is broken and has to be replaced. The library’s logs need to be audited, and this as true for glibc as it is for musl, no exception, and it’s not a one time thing, since as the libraries evolve, sensitive information can be introduced unintentionally (perhaps debugging something required it on some particular testing, and it was forgotten there).
BTW, what I meant with the language, is that no matter the language, you might unintentionally allow some sensitive information in the logs, because that’s not a syntactic error, and it’s not violating any compiling rules. It’s that something is logged that shouldn’t.
Also, the report indicates that the vulnerability can’t be exploited remotely, which reduces the risk for several systems…
True, the logging is part of the library, but it’s totally centered on what the developers are logging. It’s a bad practice to log sensitive information, which can be used by someone with access to the logs for sure, but that doesn’t mean the library is broken and has to be replaced. The library’s logs need to be audited, and this as true for glibc as it is for musl, no exception, and it’s not a one time thing, since as the libraries evolve, sensitive information can be introduced unintentionally (perhaps debugging something required it on some particular testing, and it was forgotten there).
BTW, what I meant with the language, is that no matter the language, you might unintentionally allow some sensitive information in the logs, because that’s not a syntactic error, and it’s not violating any compiling rules. It’s that something is logged that shouldn’t.
Also, the report indicates that the vulnerability can’t be exploited remotely, which reduces the risk for several systems…