Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
It's not worthy of a CVE and whether it applies to me is irrelevant. I didn't say a CVE is a black mark. Frivolous reporting of CVEs damages trust in the usefulness of the system in identifying critical vulnerabilities. This is a known issue related to resumé padding by newcomers to the cybersecurity industry.
"Frivolous" "Frivolous" "Frivolous"
Is it because it's a DOS? No. That's valid.
Feature off by default? No, that still warrants CVE.
Feature labeled Beta or Experimental? Nope, still warranted.
You must be one of those newcomers big mad F5 now has control of the record and you can't pad your cv.
Uh, no. But thanks for guessing. It's frivolous because it violates several principles of responsible disclosure. Yes, the scope of impact is relevant; the availability of methods of remediation is relevant; and the development/patch lifecycle is relevant. The feature being off-by-default and labeled experimental are indirect references to the scope of impact and availability of remediation, and the latter is an indirect reference to the state of development lifecycle. Per the developer(s)' words, this is a bug that had limited risk and was scheduled to be fixed as part of the normal development schedule. Escalating every such bug, of which the vast majority go without a CVE, would quickly drown out notices that people actually care about. A CVE is not a bug report.
"Uh, no. The CVE is valid, but it's not about that." You say, scrambling. "The dev cycle! It was already scheduled for release, so it's not necessary to disclose. If everyone disclosed security bugs, we'd have too much information and we wouldn't be able to filter for the notices we care about." You retort, not realizing that you had already conceded that this wasn't about the fact you didn't care about the CVE, and instead arguing that less information is better rather than building tools to cope with the number of CVEs that are increasing regardless of their relevance to you personally.
I didn't say the CVE was valid. I explained why it was a mistake. I didn't say "disclosing security bugs" is, in general, a bad thing, I said raising undue alarm about a specific class of bugs is bad. It's not a matter of "less or more information," because as I said, a CVE is not a bug report. It is not simply "acknowledgment of information." If you think my argument has no merit and there is no reason why "more information" could be worse, you're free to talk to someone who gives a shit.
lol and you said you weren't big mad.
If your argument is that a specific class of security bugs aren't worth CVEs, then make that argument. Instead, you're saying the CVE isn't valid and making an argument about the risk assessment and development lifecycle (as if those aren't part of a CVE) and not the class of security bug.
I have, this entire time, said it's a valid CVE that you don't care about and that you shouldn't be working as a cybersecurity professional. You have conceded the first point and continued to demonstrate the later.