Loggin (among other issues) has a security vulnerability and hasn't been updated in 3 years. Possibly replace it?
mkg20001 opened this issue · comments
There is a security vulnerability in loggin because it uses a vulnerable version of minimatch.
It has not been updated in the last 3 years and still uses gulp for all release tasks so I'm assuming it won't get an update.
Additionally it also uses the now-replaced raven package instead of "@ sentry/node" package
Could this module get replaced with some proper, more common logging library such as pino or bunyan to fix all the problems this rusty thing has?
I've also created a pr to fix those issues, but depending on something with issues that hasn't been actively maintained in the last 3 years isn't the best idea.
fistlabs/loggin#45
@mkg20001 Totally agree with this. Loggin served its purpose well but it would be good to replace it with something more supported.
The only issue I see here is that it will be a large undertaking. Unfortunately logging is pretty embedded into the code. Ideally rest-hapi could provide a custom logging module/interface that could support the logging module of choice by the dev. I'll add this as a feature request.
If you feel interested in tackling this please feel free. This is one of the many areas that has plenty of room for improvement.
Loggin served its purpose well but it would be good to replace it with something more supported.
I've released a quick'n'dirty update of loggin that seems to work fine (only 2 tests broken, mainly because of the switch from raven to sentry-minimal which doesn't have a full SDK). Maybe cherry-picking this commit would be a good idea to fix the vulns for now (after #146 has been merged)
Ideally rest-hapi could provide a custom logging module/interface that could support the logging module of choice by the dev.
This would be great. Another even better idea: Make a very tiny interface that exposes only the basic methods that hapi needs from the logger and then give the user the native logging object. (So all files in api for ex would just get the native logger without any interface wrapping at all)
That way the overhead for adding a new logger module is tiny and you won't get thousands of issues about the interface missing some functionality (ideally this simple interface could expose the same api as logging, just without the stuff rest-hapi doesn't need. that way almost nothing needs to be changed)
(By native logging object I mean the logger just without being wrapped in the interface)
@mkg20001 Yes I think that would be the best option.