It seems like it doesn't do this for Code 128 (possibly because it is variable-width?). It definitely works with EAN13 though - I tried it locally using only the TTF file.
This isn't without downsides though: As somebody with a niche technical hobby, it is hard for me to order from many suppliers because they understandably don't want to deal with consumer protection laws and thus exclude B2C transactions outright ("Verkauf nur an Gewerbetreibende").
I would be fine with waiving my right to returns but this is not possible on purpose, so my only options are to shop somewhere else (often not possible) or found a company (not possible because it would be Liebhaberei - "Running a company without intent to make profits").
B2B company in the US rarely sell to consumers either and their return policy is very different. Not necessary "no return", but only if damaged, not per spec etc. Since we don't have consumer protection laws here I guess it's based on different company structure and expected revenue. In your case it may also be VAT implications (similar problem here with sales tax).
Whenever one of these vulnerability apocalypse posts comes along I cannot help but think of the Litany of Gendlin:
What is true is already so.
Owning up to it doesn't make it worse.
Not being open about it doesn't make it go away.
And because it's true, it is what is there to be interacted with.
Anything untrue isn't there to be lived.
People can stand what is true,
for they are already enduring it.
I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
Imagine somebody finding a flaw in a mathematical proof and everybody being sad because a beautiful proof got invalidated rather than being glad future work won't build on flawed assumptions.
I get that the rate of vulnerability discovery can be a burden, especially for people doing FOSS in their spare time, but the sustainability problem with that has always existed and only gets exacerbated by the vulnerability stuff, but the latter isn't the cause you need to make go away.
To address this framing directly: "a bug exists" is a different truth/state of the world than "the bug is known to exist", and that's also very different from "this bug exists and an exploit is readily available". So the transmission of information about the bugs does change the state of the world, and requires action.
As an outside observer, there is no way for you to determine if a bug is in state one or two, you only know once it's in the third state.
Which is the entire problem here. Having the bug be known to everyone is a vastly improved state over being known to a few. Yes, the bug being completely unknown is better than being known to a few, but there is no way to ever know if that's the case.
From the outside, known to none and known to a few are indistinguishable, and thus both states are the worst possible case. The only remedy is to make the bug known to everyone such that it cannot be covertly exploited.
That's not the whole picture though. Bugs exist anyway. The only practical concern is, which are practically most likely going to be used among all these bugs that yes exist and included in production.
You've described states one and two as outlined above.
Whether a bug is exploitable is an entirely separate category of unknowable, because seemingly-innocuous bugs quite often have very deep and very subtle implications that when combined with another innocuous bug, result in an RCE or PE.
Therefore, it's sensible to treat all bugs as potential threat vectors unless and until proven otherwise. Which brings us full circle: state 3, all bugs being public, is probably the safest thing because nobody can know if a bug is in state 1 or 2.
It's sensible just as it's sensible to have invulnerable immune system.
Sure, who wouldn't like to have that? Such a thing is impossible to reach starting with the same reason as Gödel's incompleteness theorem is a thing, plus a gazillion of more practical constraints.
A bug existing or not for a person is a statement about that person's knowledge of the bug.
Is your assertion that, since you specifically didn't know about the bugs that nobody, not in Russia or anywhere else did?
Obviously if bugs are out there existing in software and you don't know about them, or the CVE system doesn't know about them, or whatever ... this does not preclude bad guys from knowing about them. In the era of agents, knowing the bug exists is equivalent to having a PoC, so the distinction completely collapses.
Arguably, the transition goes from - this bug exists but vendors ignore it because only criminals and intelligence agencies know about it to, this bug is publicly embarassing lets fix it right away.
Sweeping things under the rug is how we get insecurity. Sunshine is the best disinfectant.
> Imagine somebody finding a flaw in a mathematical proof and everybody being sad because a beautiful proof got invalidated rather than being glad future work won't build on flawed assumptions.
Is this supposed to be hard to imagine? I can completely imagine this, especially if the mathematician is a celebrity in their field.
In theory, the vulnerability was always there, and it's better to find out than not find out.
In practice, how much effort it is to find vulnerabilities matters a lot. We're in a time where things that used to be quite hard are now easy and the rate of discovery will change.
This rate of discovery matters a lot -- for OSS maintainer burnout if nothing else.
It matters in a positive sense; it's a thing that enables you to make some predictions about the state of the world tomorrow. It does not matter in a normative sense; OSS maintainer burnout is strictly a less important concern than software security, which is an externality of software development.
> OSS maintainer burnout is strictly a less important concern than software security,
Burnout means that no more fixes come - ever - and that things sit vulnerable until everyone relying on that tool takes the time to build and switch to a replacement.
Maintainer burnout is perhaps the single biggest threat to the ecosystem right now.
That can't possibly be an argument for forbearing security vulnerabilities in software. It's an argument for prioritizing hypothetical flaws over real ones.
If these flaws are so important, users of open source (business or individual) need to pay up - literally. Pay the maintainers enough to justify spending the time on these things, including the opportunity cost of not working at other software jobs during that time.
Pay each maintainer an absolute minimum of $200K a year or shut up and do the work yourself - in a fork if necessary.
This comment should not be greyed out. I feel that we all forget this far too much. You've exaggerated it somewhat.
There is no right to demand someone does something for free, and we have gotten dependent on people doing things for free. We don't have to pay people but if we don't want to, then we have to be willing to do it ourselves. Otherwise it could go away at any moment and we have no recourse.
Stated differently -- the way OSS software is currently maintained and users are conditioned to behave, there is a capacity problem if the rate of discovery surges too sharply.
And if the capacity is overshot (which I believe is happening as we speak), users end up in extended states of being insecure.
I'm also one of the unwashed rabble who believes there is a large practical difference between a vulnerability that exists but isn't found and one that is widely known and exploitable.
There's two fallacious arguments encoded here. The first is obvious, that we should prioritize hypothetical future vulnerabilities and fixes over ones we know exist today. The second is subtler and more insidious: it's the idea that the goal of software is to ensure every package and project is viable, that everyone who wants to deploy it should be able to do so. The risks this attitude pose to users, ordinary people who have no agency over which software packages you use to serve their needs, are a pure externality. The idea that a project serving real human users might opt to compromise availability rather than putting people at risk is never even broached.
This is so far outside of reality that I can't believe I'm even commenting on it.
If you believe people don't use software that is unmaintained and hilariously out of date I genuinely don't know what world you live in or how to deliver the bad news to you.
Oh, I agree that today there's a general expectation that externalized security doesn't matter and someone will always come around to rescue you (and your unmaintained dependency) from disaster. I'm just saying: infinite free bugs is likely to disrupt that equilibrium.
> I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
I don't think anyone is saying that here.
I think the net result is "wow, we're going to end up a lot more secure in several months, but things are going to feel sucky because stuff just got A) way easier for the average bad guy, and B) way busier on the fixing side."
I think it's likely we end up with an equilibrium with a lower rate of bug discovery than we're used to, but we need to experience an above average rate for a long while first...
> I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
Try binge-watching old Star Trek episodes, to see how Spock deals with the illogical 99.9% of humanity?
Apple implements the USB-C/USB PD specs to a t and is unforgiving if you don't do either.
At work, our quick test for if a device implements USB PD correctly is to plug it into an Apple power supply (optionally with a PD protocol sniffer in line). If it doesn't work (either no/intermittent VBUS or the wrong VBUS), it's always been the case that the device is doing something wrong.
It can be annoying but strictly speaking their fault.
Obviously the two aren't the same (especially given the need to do routing), but I've always found it amusing that in the systems world, capability-based systems (i.e. making it impossible to address things you aren't allowed to access) are gaining traction while the philosophy in the networking world seems to be going in the opposite direction (make it possible to address everything, i.e. IPv6 vs. NATted IPv4, then add filtering).
Calling publishing API docs "open-sourcing" is a bit hyperbolic, but as token gestures go, it's at least worth a little bit.
I'm not familiar with those devices in particular, but I wish vendors would take steps to make life easier for after-markt firmware developers especially once devices go EOL by doing things like proactively dropping a GPL tarball and giving people a way to disable secure boot locks on devices that have them.
Sure, but then it is set to no-touch for every FIDO2 interaction I have. I don't want to touch for signing, but I want to touch when using it as a passkey, for instance.
Use the PIV applet for SSH and signing Git commits instead? Git supports S/MIME and SSH can use keys over PKCS#11 basically out-of-box on OSs that don't ship gpg-agent (that just interferes with SmartCard usage in general).
L4 was a microkernel design by Jochen Liedtke (RIP). It was notable for proving that microkernels can perform much better than was thought at the time (L4 performed 20x better than the Mach microkernel).
The work was so influential it got the ACM SIGOPS Hall of Fame Award in 2015. A whole family of microkernels based on that original design have since been developed, hence the "L4 microkernel family".
It's still not perfect since you're still leaking information about the privacy set implied by the outer ClientHello, but this possibly isn't much worse than the destination IP address you're leaking anyway.
