Sadly the inclination of the orbit prevents it from falling that far north.

For local communication Microsoft Visual Studio Code often uses TCP sockets (bound to localhost) even though UNIX sockets are available. What's more, old versions used to pass the authentication token as a command-line argument, exposing it to all users on the system.

I wonder how many other security disasters it contains that nobody has discovered yet.

Despite the sad context, this seems refreshing -- an alert is raised due to a real and serious concern.

It is nice that things aren't so bad that nobody is even keeping an eye out for things like this. There's some comfort in knowing that somewhere smart people are looking into it.

The part of the policy about distributing modified versions of the Rust compiler seems interesting:

> Publicly distributing a modified version of the Rust programming language, compiler, or the Cargo package manager, provided that the modifications are limited to:

> - code adjustments for the purpose of porting to a different platform, architecture, or system, or integrating the software with the packaging system of that platform

It looks like distributing a modified version with any change that isn't related to compatibility with a different platform/architecture/system is not allowed. This would probably make almost all GitHub forks of Rust non-compliant.

The way I read it the intent is to ensure there is one sanctioned version of Rust, if you change the compiler to accept other syntax, different file types etc you have to call it by another name. You can still say that it's written in rust and compatible to rust, but you can't call it rust. A weaker version of that policy Firefox had for a while.

Maybe the exact wording needs some refinement. Allowing repositories that are marked as forks for example.

> The way I read it the intent is to ensure there is one sanctioned version of Rus

basically that

Through it's very annoying that it needs refinement _again_ and _again_ every f* time they update the trademark policy.

Like why

- is there no exception for research (i.e. science) use, as long as explicitly labeled at such

- public development forks which are used to prototype directions rust could go into, again if clearly labeled as such and not maintained as forks (through to be fair the line between a public experimental rust development fork and an early rust "full" fork are thin)

- wrt. software compatibility allowance why is it limited to the "packaging system of that platform" can't I fork to idk. create compatibility with a code analysis tool, changes I then later want to upstream but first need to test so need to distribute to various people?

and sure you will normally get written permission for all the cases above, just the chance that someone could abuse this preventing you from doing very reasonable thing is IMHO an issue. I really don't want to see a headline like "rust forbids <company> from creating a compatible code analysis tool because <some stupid issue>".

This is a trademark policy, not a copyright license (Rust is distributed under MIT and Apache licenses, which are quite liberal in what you are allowed to do). You're welcome to make changes and distribute the modified versions, but you do have to be clear to people that it's not Rust, but DathinabRust etc.

> This is a trademark policy

exactly

but if you distribute something containing a trademark and the trade mark policies don't allow distribution it is pretty much automatically a gray area of trade mark infringement

i.e. you do a clone of the rust repo and a some changes is with the current form of the draft trade mark infringement as long as you don't also at least 1. rename the repo, 2. update the readme

but even if you do it might still not be enough

trademark law as it currently is can easily be ab-used as an additional form of copy right protection and as long as you don't replace any occurrences of rust/cargo you are always trading in a potential gray area of law which can be abused

and who wants to contribute under such circumstances?

also who wants to contribute if they have to change the readme/repo name just to make a bug branch but then also not have it in the PR you submit, but also needing to have this changes in any branch including the PR ...

> if you distribute something containing a trademark and the trade mark policies don't allow distribution it is pretty much automatically a gray area of trade mark infringement

The whole world is shades of gray, but this is more like a wispy cirrus cloud than a dark cumulonimbus. If it's clear that there's no intent to cause confusion (and I suspect that if you're not creating releases in that repo that would be a pretty easy case) then there's not really much of a trademark infringement case to be made.

In the absence of such a trademark policy you'd have the exact same concerns. Them trying to go after people who fork on github would be a waste of time for everyone concerned: there would be no damages unless they went through the trouble of finding someone who had somehow actually been confused, and a C&D would accomplish nothing positive for the Rust Foundation anyway.

> - is there no exception for research (i.e. science) use, as long as explicitly labeled at such

It's fine, researchers won't be harmed by having to find a cheesy name for their rust-based project. Actuality they probably don't even need a trademark policy for doing this.

You need a name for your project when writing papers anyway.

The word “Rust” is all over the code repo, you’d need to do a massive change and you’ll lose the ability to merge upstream changes. “Rename the repo if you’re doing something meaningfully new with no intent to merge it upstream” is fine, but it’s not enough to avoid saying “Rust” in the version you distribute.

it's about the issues I mentioned in the other response, not about them using rust in some science project

it's quite easy to accidentally commit trade mark infringement if there is a restrictive policy about it and you "just fork on github"

while in many situations law cases probably would be shut down legal instability helps no one

Note that part is unchanged from the current trademark policy here: https://foundation.rust-lang.org/policies/logo-policy-and-me...

(Except the current policy says "Distributing" rather than "Publicly distributing".)

I don't think we can argue in good faith that those forks are publicly distributing a modified version of the rust programming language, unless they actually publish releases.

I don't know, to me it just seems like a plausible interpretation:

- In GitHub, forks of public repositories are themselves public repositories.

- GitHub repositories can be cloned, which is a form of distribution.

- Therefore any fork that implements, for example, a change to the programming language itself, but still uses the name "Rust", is distributing a modified version of the programming language in a manner that is not allowed.

I sincerely hope that this is not the interpretation taken by the Rust Foundation, but I cannot know for sure. It seems very open to selective enforcement.

It's an argument a lawyer could make in court with a straight face. But that's not the same as an argument likely to win in court. The fundamental purpose of trademark is protecting commercial purity of a product; a GitHub fork whose relation to the original is pretty clearly stated and isn't trying to present itself as a viable alternative to the original is just unlikely to be seen as in the purview of trademark protection in the first place.

Arguing that it's covered because it's distribution requires chaining through a few overly literal definitions to achieve that result, and that isn't likely to be winning argument against a gut instinct of "no, it's just not."

in good faith, no. Legally, yes.

But legalities have its costs as well. is it worth it to go after some random student project with no stars on it? Absolutely not. I imagine that's the bulk of those github forks.

The demo appears too stateful for me. The real power of `jq` is its reliability and the ability to reason about its behavior, which stateful tools inherently lack.

> an obscure instruction

Come on, vpternlog* is not obscure. It subsumes _all_ bitwise instructions, even loading the constant (-1) into a register.

Not if, like most people, you still aren't using a CPU with AVX-512 support. And I don't recall ever seeing it in compiler output in any case. It's not like boolean operations on three variables occur very frequently in most programs, especially (EDIT: this last part apparently isn't the case) not operations that can't be decomposed into a pair of two-variable operations with no worse performance.

As far as everything on uops.info goes, ternlog has the same throughput and latency as the two-operand logic instructions everywhere (with the mild exception of Zen 4 where it goes from 0.50 to 0.56 cycles/instr; which also shows as having 2-cycle latency to one operand but I think that might be measurement error), so it's always bad to decompose ternlog into two two-operand logic ops.

I've been running Hyprland for a while now. I find its window management capabilities quite good, in particular, the default 1 LHS / n RHS setting -- I lack the desire to deal with binary trees; the window manager should manage the windows, not me.

That being said, I am a W^X person so I don't really like some of the (x86_64-specific) aspects of their plugin systems. I need to publish my #ifdef-it-out-with-fire patch at some point...

W^X? I've never seen that term

Is 26 characters next? I think the number of bytestrings of length <= 26 that are also valid UTF-8 is only 0.021 * 256^24.

I think the problem you encounter with this is that you can no longer reference the small string as a &str.

(2024).

Assigning a CVE to every second commit and refusing to assign CVEs to unfixed issues doesn't seem like correct usage of the CVE system. I expect that most Linux CVEs will never get a proper analysis or a CVSS rating.

To me it sounds plausible that the design goal of the Linux CNA is to show that CVEs don't meaningfully apply to the Linux kernel. Given how dependent on context the impact of some kernel bugs can be, if we were assigning CVSS scores for the worst case, practically all kernel bugs would be at least a 9.8/10.

> I expect that most Linux CVEs will never get a proper analysis or a CVSS rating.

You're free to contribute your own analysis and CVSS rating.

No, the problem needs to be fixed. Adding more noise isn't helpful at this point.

Ah, you're paying for some enterprise Linux subscription, then? So that the vendor can on your (and others') behalf influence the kernel devs that they are funding?

What? No, the kernel devs just have stop acting like idiot children in this regard.

Ah, yes, of course!

I hope you're aware this says a lot more about you than it does about kernel devs :)

Honestly, I think your reactions just show that you don't really understand why the kernels devs behavior in this context is so childish and irresponsible.

Looks like you have some reading to do :)

k so I'm writing a blog post on the whole #Linux Kernel #CVE/#CNA thing. And I actually looked at the data. For those of you complaining about the Linux Kernel issuing improper CVEs my response is "cool. If they're not security vulns get them rejected".

So far in 2024 the Linux Kernel error rate is 3.21%.

Is that bad or good?

Let's compare to the top 25 CNA's by error rate for 2024:

f5 49.32%

atlassian 44.44%

Esri 43.75%

freebsd 40.00%

canonical 32.61%

Gallagher 25.00%

SNPS 25.00%

intel 19.74%

Anolis 18.75%

Dragos 18.18%

rapid7 14.29%

@huntr_ai 12.27%

Google 10.00%

directcyber 8.33%

CERTVDE 8.11%

Go 7.69%

lenovo 6.25%

mitre 5.53%

schneider 4.35%

GitHub_P 4.35%

Fluid Attacks 4.35%

Wordfence 3.56%

Linux 3.21%

snyk 2.94%

So... Linux is in at 24th place for error rate. But wait, surely those numbers are skewed towards some smaller CNAs that reject a handful of issues driving up their error rate?

Nope. Several of the mature CNAs like F5, Atlassian, Canonical, Google, Intel, Red Hat, Lenovo, MITRE all issue tens to hundreds to thousands of CVEs a year and have much higher error rates. Actually the worst CNA by raw numbers is MITRE (159).

Spamming this multiple times since people don't seem to read.

Turns out F5 and Intel were just clearing out old reservations, but the other data is correct.

> To me it sounds plausible that the design goal of the Linux CNA is to show that CVEs don't meaningfully apply to the Linux kernel.

I think it's hostile in nature. The core kernel devs have a horrible attitude toward security vulnerabilities.

Yes, my original wording was "to make the CVE system burn", but that got lost during my tone-down edits.