jstasiak

This is a pretty unfortunate name choice, there's already a project named OpenClaw (a reimplementation of the Claw 2D platformer): https://github.com/pjasicek/OpenClaw.

Same here, Firefox 147.0.2, macOS 15, Apple Silicon. "Firefox GPU Helper" keeps using 30-40% of a CPU core.

I think it's not strictly connected to using YouTube in my case.

The package has now been restored/reinstated: https://web.archive.org/web/20250723155529/https://www.npmjs...

This has been reflected in a recent edit and comments here: https://github.com/stylus/stylus/issues/2938

No updates to the security advisory at this time: https://web.archive.org/web/20250723155624/https://github.co...

Great thing about entropy is that adding more never hurts.

I used to think the same but here's a counter-example of a (hypothetical) attack based on a malicious entropy source being able to manipulate the hash/PRNG output:

https://blog.cr.yp.to/20140205-entropy.html

Now, it's not necessarily the most likely attack to materialize, as already pointed out downthread: https://news.ycombinator.com/item?id=43391377.

Adding +1 to the Nebula recommendation.

The last time I tried ZeroTier (years ago, I admit) it wasn't possible to self-host all of it I think and I couldn't make it reliably use my own relays for good performance of non-direct connections.

I've been happily using Nebula for a while now, pretty easy to configure and self-host.

Looking at that file may make you reach misleading conclusions. Some tun/io code may be use but there's that. As far as I understand WireGuard the protocol is not used anywhere:

  nebula (master)> git rev-parse HEAD
  2b427a7e8934f0a436fea25eb40a6b979b34ee7a
  
  nebula (master)> rg --glob '*.go' -i wireguard
  wintun/tun.go
  6: * Copyright (C) 2018-2021 WireGuard LLC. All Rights Reserved.
  9://NOTE: This file was forked from https://git.zx2c4.com/wireguard-go/tree/tun/tun_windows.go?id=851efb1bb65555e0f765a3361c8eb5ac47435b19

  udp/udp_rio_windows.go
  4:// Inspired by https://git.zx2c4.com/wireguard-go/tree/conn/bind_windows.go
  25: "golang.zx2c4.com/wireguard/conn/winrio"

  overlay/tun_wintun_windows.go
  17: "golang.zx2c4.com/wireguard/windows/tunnel/winipcfg"

  wintun/device.go
  6: * Copyright (C) 2017-2021 WireGuard LLC. All Rights Reserved.
  9://NOTE: this file was forked from https://git.zx2c4.com/wireguard-go/tree/tun/tun.go?id=851efb1bb65555e0f765a3361c8eb5ac47435b19

They're solutions to slightly different problems.

I'd characterize it as such: Wireguard is more of a plumbing solution that gives you a point-to-point connection, either it's enough for you or you can use this to build what you need.

Nebula is more of an end-user ready-to-use solution, gives you features like NAT traversal, automatic selection of direction connections if possible, the nodes don't need to know other nodes' addresses ahead of time(x) etc.

(x) except for the lighthouse

An article mentioning this kind of attack: https://blog.cr.yp.to/20140205-entropy.html

I've had some contact with Docusaurus and from my experience the Sphinx and reStructuredText combo is a much better solution to creating a robust, maintainable, cross-linked-to-nth-degree documentation where you actually can "focus on your content".

Bonus points if you prefer to not deal with the JS ecosystem and prefer Python.

The main downside is that while reST is well-suited for extending the syntax actually writing Sphinx extensions is, subjectively, significantly more arcane than writing React components/MDX plugins.

A recent discussion on this topic, part of the "I prefer rST to Markdown" submission: https://news.ycombinator.com/item?id=41120772

Wouldn’t it be simpler and more consistent to have a first parse the IP into an internal format then perform all logic on that?

So not speaking about this library specifically but yes, separating the address parsing part (https://www.netmeister.org/blog/inet_aton.html is a fun read) from the "is this address considered private?" part should make things much simpler.

Vast majority of related code in this space that I've seen works like that. I'm actually struggling to come up with counterexamples.

Tangential, but thought I'd mention this

The CVE has to do with the utility not correctly identifying private IP addresses supplied to it in a non-standard format, such as hexadecimal. This would cause the 'node-ip' utility to treat a private IP address (in hex format) such as " 0x7F.1..." (which represents 127.1...) as public.

Things aren't necessarily as simple as they appear.

There's this thing called IANA IPv4 Special-Purpose Address Registry[1] and it lists some address ranges labeled Private-Use, it's the usual suspects: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

The table also has a Globally Reachable column. Some special ranges, including but not limited to Private-Use above, have Globally Reachable set to false.

Some others, like Direct Delegation AS112 Service (I don't know what it actually is), are listed as actually Globally Reachable.

So I'd say there are at least three plausible interpretation of the word "private" in this context:

1. IPv4 or IPv6 address, listed as a special range and Globally Reachable = false (caveat: for some IPv6 ranges there can be N/A in that column[2], more choices to make) 2. These IPv4 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 3. All special ranges from [1] and [2], we don't want to try to contact any of these

For example Python's ipaddress mostly follows interpretation 1 while Rust standard library[3] and Python's netaddr[4] (disclosure: I maintain it) effectively follow interpretation 2.

From the point of view of a library author the semantics of what's private, what's public, global, etc. needs to be documented very well and examples provided.

From the point of view of a library user the documentation needs to be consulted (and tests performed) to make sure the library semantics match assumptions/expectations.

It all gets complicated rather quickly.

[1] https://www.iana.org/assignments/iana-ipv4-special-registry/... [2] https://www.iana.org/assignments/iana-ipv6-special-registry/... [3] https://doc.rust-lang.org/std/net/struct.Ipv4Addr.html#metho... [4] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IP...

Credit aside, if this is mostly your code there may be a copyright/license issue.

The original license: https://github.com/rubberduck-ai/rubberduck-vscode/blob/f11a...

The new project: https://github.com/srikanth235/privy/blob/9b4f8ce7e176ab45d5... no mention of the original copyright

Looks like a great initiative – I wish there was a reliable TS/JS equivalent of https://docs.rs (even considering rustdoc's deficiencies[1]).

I went through this exercise recently and so far my experience with trying to produce documentation from a somewhat convoluted TS codebase[2] has been disappointing. I would claim it's a consequence of the library's public (user-facing) API substantially differing from how the actual implementation is structured.

Typedoc produces bad results for that codebase so sphinx-js, which I wanted to use, doesn't have much to work with. I ultimately documented things by hand, for now, the way the API is meant to be used by the user.

Compare:

https://ts-results-es.readthedocs.io/en/latest/reference/api...

vs

https://tsdocs.dev/docs/ts-results-es/4.1.0-alpha.1/index.ht...

https://www.jsdocs.io/package/ts-results-es#package-index

[1] https://github.com/rust-lang/rust/issues/66249

[2] https://github.com/lune-climate/ts-results-es