Primarily because OP can't verify that the patch is truly correct. There's also the fact that anything LLM-generated will likely be frowned upon (for the same reason).
With some effort OP could review it manually and then try to submit it though.
But QEMU uses a mailing list for development, it's tedious to set up and then later keep track of. I now fundamentally refuse to contribute to projects that use mailing lists for development, the effort it takes and the experience is just so horrible.
Especially if it's a small patch that doesn't concern anyone (any big sponsors), you'll probably never get a response. Things get lost easily.
It heavily depends on what you mean by "not the code", if all the code does is implement the necessary steps for the interface, then it's part of the interface. It's an interpretation of an interpretation of a datasheet.
Yes, but how on earth is their malicious compliance at providing parental controls a good reason to go for the surveillance state that hurts absolutely everyone?
Social media operators love the surveillance state idea. That's why they aren't pushing against this.
I even cancelled YT Premium because their "made for kids" system interfered with being able to use my paid adult account. I urge other people to do the same when the solutions offered are insufficient.
I have seen LLMs be surprisingly effective at figuring out such oddities. After all it has ingested knowledge of a myriad of data formats, encryption schemes and obfuscation methods.
If anything, complex logic is what'll defeat an LLM. But a good model will also highlight such logic being intractable.
The biggest war on small providers is waged by other small providers. They can be ancient and outdated or simply extremely picky. Which makes everything Google or others require a piece of cake, which it actually kinda is.
That's exactly what prosody is doing, but it's a weird solution. Essentially, they're just ignoring the missing EKU flag and pretend it would be there, violating the spec.
It seems weird to first remove the flag and then tell everyone to update their servers to ignore the removal. Then why remove it in the first place?
I think you're confusing different actors here. The change was made by the CA/B Forum, the recommendation is just how it is if you want to use a certificate not for the purposes intended.
But it does mean that the CA/B requirement change has zero positive effect on security of anything and only causes pointless work and breakage.
Or to put it another way, the pragmatic response of the XMPP community shows that the effect of the change is not to remove the clientAuth capability from any certs but to effectively add it to all serverAuth certs no matter what the certificate says.
Yes, this is what is happening. It isn't happening fast enough, so some implementations (especially servers that don't upgrade often enough, or running long-term-support OS flavors) will still be affected. This is the impact that the original article is warning about.
My point was that this is yet another change that makes TLS operations harder for non-Web use cases, with the "benefit" to the WebPKI being the removal of a hypothetical complexity, motivated by examples that indeed should have used a private PKI in the first place.
Not forbidden, just not going to be a part of WebPKI.
It's one of those things that has just piggybacked on top of WebPKI and things just piggybacking is a bad idea. There have been multiple cases in the past where this has caused a lot of pain for making meaningful improvements (some of those have been mentioned elsewhere in this thread).
The current PKI system was designed by Netscape as part of SSL to enable secure connections to websites. It was never independent of the web. Of course PKIs and TLS have expanded beyond that.
"WebPKI" is the term used to refer to the PKI used by the web, with root stores managed by the browsers. Let's Encrypt is a WebPKI CA.
The idea of a PKI was of course designed independently, there are many very large PKIs beyond WebPKI. However the one used by browsers is what we call WebPKI and that has its own CAs and rules.
You're trying to make it sound like there has ever been some kind of an universal PKI that can be used for everything and without any issues.
With some effort OP could review it manually and then try to submit it though.
But QEMU uses a mailing list for development, it's tedious to set up and then later keep track of. I now fundamentally refuse to contribute to projects that use mailing lists for development, the effort it takes and the experience is just so horrible.
Especially if it's a small patch that doesn't concern anyone (any big sponsors), you'll probably never get a response. Things get lost easily.
reply