Hacker News Reader

Comment by mdeeks | Hacker News Reader

Discouraging? Huge understatement. An auth plugin that refuses to fix multiple high severity vulnerabilities is wild. No one should use this plugin for anything. If I were the Caddy authors I would remove all references to this project and ask that they stop use of the Caddy name.

View on HN

There is no "refusal" as far as I can tell. The issues were reported [1] in September 2023 (as was this blog post) and the simplest one has been fixed (insecure random seed). I'm not aware of any public statements from the plugin maintainers, and there is no hostility in the issue comments.

[1]: https://github.com/greenpau/caddy-security/issues?q=is%3Aiss...

If there isn't a refusal, fair enough. Yet leaving high impact, publicly disclosed security issues unresolved for 6 months means the code is abandoned.

I'll consoder stable code fine without new releases for years even, but security issues? Responses and fixes need to be measured in days, not months.

(Some may say "but what about"..., and note all rhe conditions I listed above. Publicly disclosed + timefame. Doesn't matter who it is, big or small, 6 months means the software maintainers show no serious commitment to security, and one should run to other solutions.)

PRed welcomed

I mean, do you feel you have a right to get those fixes for free? I'm sure you are welcome to contribute them.

No, but I'd also hope that new and existing users of what's probably a popular middleware for Caddy aren't expected to read 100's of open GitHub Issues or luck upon the Trail of Bits report to know there are significant unresolved security issues and the maintainers don't have the time or resources to actually fix them.

Better know that up front, than get popped and think "What happened?".

At the very least, there should be a clear warning not to use the current version of the software. And I think it's reasonable to suggest that the main project authors should neither advertise software that's dangerously insecure nor allow it to use the main project's name (which could mislead people into assuming that it's part of the project and similarly well maintained).

> which could mislead people into assuming that it's part of the project and similarly well maintained

That’s entirely on the idiot that assumes a similarity in name means the project is maintained by the same owner.

I don't understand this attitude.

If you put your work in the open, advertise it as an officially supported solution, and advertise it as secure, it had better be supported and secure. You can't just put out broken software and hide behind "but you didn't pay for it so who cares." Even worse when the attitude is "it's not my fault, go fix it yourself and submit a PR."

If that is the intent, why even open source it in the first place and tell people to use it. Just keep the code private and use it for yourself.

Over the last decade I have written hundreds of thousands of lines of code for personal projects that will never see the light of day, precisely for this reason. It's not production-quality software, and it would be horrendously irresponsible for me to put it out in the open, advertise it, and tell people to use it, compromising the security of their homelabs (or worse, enterprise deployments).

you're describing proprietary software with a full support contract.

the point of free software(tm) is gaining benefit from cooperation and community, and nobody is obligated to do anything.

Reply on news.ycombinator.com