Wireguard is not connection based, so a full-mesh VPN with n nodes essentially just means each node has n-1 peer keys and maintains a routing table with n-1 entries for the VPN.
> Actually, they can set a different IP for each session and rotate them by given it to the client out of band, for example when it authenticates to the service.
Like I said, Wireguard does not have the concept of sessions. You could add your own proprietary "stuff" around Wireguard to add that concept, but then you don't need anything extra from Wireguard. You add the keys of the users as part of the session setup and remove them when the session is destroyed. Of course, this means that clients have to use a client tool provided by you.
What they want to do, cannot be done by Wireguard, because Wireguard does not have the concept of "VPN sessions / connections". What they probably need to do is to assign each customer a fixed private IP for use within their VPN, e.g. from 10.0.0.0/8.
When those are not enough any more, they need to segment their VPN, so they can re-use the private IP space in each segment.
w.r.t. to "NeuroRouting and TrackStop not possible", they could route their stuff through a TUN interface to do whatever they want to do in user space. With a performance cost.
It's a kernel module. What you do in practice is to have a configuration file somewhere and then have a command line tool (wg(1)) read that file and have the wireguard kernel module create a wg0...n network device.
The out of kernel alternative is how OpenVPN has always worked, by creating a TUN/TAP device, which basically creates a pipe<->network device bridge, and a user space process reading/writing from that pipe.
It's a myth that electronics design is math-heavy, because you can do it with pretty much just +-/ and some ² and roots. Even for e.g. filter design you don't actually need to be able to do (or even understand) any of the calculations yourself, because tools automate it away. Analog design with "basic blocks" is pretty straightforward, "free form design" not following basic blocks (usually resulting in part count reductions or performance enhancements) is much harder. The latter is what often produces "trick circuits" which most people cannot analyze on their own and possibly cannot analyze using SPICE.
Connection refused is way better for the average server stack than timeouts or even worse accepted connections with transfer rates of 30 seconds per byte. "Connection refused" is a huge signal flare going off instantly, timeouts and extreme slowness will by definition take longer to notice while impacting systems, even if your monitoring were perfectly set up to look for it.
Swap and paging are different concepts. The VM can page clean pages (mmap'd files, like most code your system is running) from disk in and out all day if it wants, in fact, when Linux is thrashing, that's exactly what it's doing.
Linux absolutely, positively, requires a decent chunk of free memory because the kernel's algorithms simply do not work and in my 15+ years of Linux experience they NEVER worked. If Linux starts thrashing, and it does so easily, then the box takes what surely is an uncomputable amount of time to recover.
One way to make relatively sure that this is always the case is to use a userspace daemon like earlyoom.
Though to stay fair all desktop OS'es behave badly when put under memory pressure, it's just that Linux is an order of magnitude or so worse.
> Garbage Collection involves crawling live objects from roots to determine what's still alive.
> If you're not doing that, you might still be doing automatic memory management, but you're not doing GC.
Whether GC and automatic memory management are [significantly] different terms depends on who you ask, I don't think there is a consensus on that. In many cases however people tend to say GC as shorthand for tracing GC.
I think in many cases we see ARC is "good enough", and in a JIT scenario you could remove many RC changes by effectively collapsing/merging scopes. OTOH it is quite clear that for the same workload tracing inevitably performs better.
I would never argue they aren't, but by this logic ("it's like saying PDF or JPEG parsers can't be vulnerable to RCE") virtually every code execution vuln in a library can be called RCE. I haven't noticed this to be the case with e.g. libtiff vulnerabilities (of which many make it into my inbox regularly), although image libraries are one of the cases were CE = RCE is still fairly reasonable.
Let's assume this SQLite bug is only exploitable if you can input arbitrary SQL. Almost no applications use it this way (except Chrome). I think it's clearly unreasonable to call it a RCE in SQLite then.
> The fact that Chromium also saw fit to patch this suggests further that there was likely some way that it could be tricked into issuing queries that did this, allowing some compromise of the browser. If this could have been triggered by a web page, then that explains why they are light on details.
Chromium still supports WebSQL, though, which gives you essentially free reign on a SQLite database. This is quite different from the way most applications expose SQLite to untrusted data (i.e. only through parameter binding).
An RCE in a non-networked component is interesting (in other words, obvious hyperbole). Either this is your usual corruption bug/vuln triggerable in some/many programs using SQLite, or an actual bug in SQLite itself, e.g. query preparation (a fix/workaround being committed to SQLite doesn't necessarily imply one or the other). Whether the RCE hyperbole is justified remains to be seen.
Edit: Apparently the exploit vector is due to WebSQL.
And my guess as for the vulnerability area are "strategically corrupt databases", because there have been numerous commits related to this in the relevant SQLite releases and some seem like they were added relatively late in the process (e.g. after changing the VERSION file but before releasing).