Hacker Newsnew | past | comments | ask | show | jobs | submit | swinglock's commentslogin

Because it's there.


It hasn't for the most part of the last 2 decades.


The telnet client comes with MS Windows, Linux and macOS. The only platforms were you need to install some extra component are Android and iOS.


Are you sure? I can't seem to find the Linux implementation anywhere in the repo https://github.com/search?q=repo%3Atorvalds%2Flinux%20telnet...

You are absolutely right: s|Linux|GNU/Linux|

Many companies have been preventing its execution or removing the package by default for a number of years.

Also most linux containers do not ships with such binaries to save on img size and reduce vuln management overhead.


> to save on img size

    $ ls --human --size --dereference $(which telnet)
    144K /usr/bin/telnet


The point is not that this particular binary is huge, the point is that we tend to strip images of anything that is not useful for the actual application shipped. So we strip everything. Also: small things adds up. On AI prompt can be handled reasonably by a single machine, millions of concurrent ones involve huge datacenters and whole energy plants being restarted/built.

The point of reducing the amount of binaries shipped with the image is also to reduce the amount of CVEs/vulns in your reports that wouldn't be relevant for your app but woulld still be raised by their presence.


Telnet client is an optional feature in Windows that needs to be enabled/installed.


telnet hasn’t shipped with macOS since 10.12 Sierra, ten years ago.

Debian also isn’t shipping telnet in the base install since Debian 11.


Thanks, sounds like a recent development. I don't use macOS, but on other peoples macOS computer it was always there, even when they are not developers. But it could very well be that these computers are ten years old.

I mean technically MS Windows 10 is ten years old, but the big upgrade wave to 10 only happened like 4 years ago, which is quite recently. Maybe that is similar to macOS users, I don't know that.


Something breaking after 49.7 days is a classic. Someone counted milliseconds since start with a 32 bit unsigned int and some code assumed it couldn't wrap.


Win32 and Wine being a lightweight alternative to HTML and Electrum is a fun idea.


Wine is going to require at least as much disk space as Electron. Performance and memory usage should at least be better though.


This is why I used ReadItLater and now Instapaper. It's integrated in my ebook reader too.


Subscription Bookmarking apps will never be part of my workflow.


There are self-hosted options too. I can't vouch for any of them but many look competent.


Men in the middle including predatory ISPs can not only spy but also enrich. Injecting JavaScript and embedding ads is the best case scenario. You don't want that.

In addition even without bad actors TLS will prevent random corruption due to flaky infrastructure from breaking the page and even caching those broken assets, preventing a reload from fixing it. TCP/IP alone doesn't sufficiently prevent this.


> JavaScript

Why do you allow that RCE in the first place?


Most users have JS enabled nowadays. Much of the web doesn't work without it. It was just an example.


TCP ensures what gets sent on one side gets received on the other side. TLS just encrypts the data. So even without TLS, random corruptions won't happen unless someone does MITM attack.


No it does not. I've had this happen in legacy systems myself. The checksums of TCP/IP are weak and will let random errors through to L7 if there are enough of them. It's not even CRC and you must bring your own verification if it's critical for your application that the data is correct. TLS does that and more, protecting not only against random corruption but also active attackers. The checks you get for free are to be seen only as an optimization, letting most but not all errors be discarded quick and easy. Just use TLS.


I saw myself years ago that Verizon injected marketing tracking headers into http traffic. My ISP was the MITM.

https://www.eff.org/deeplinks/2014/11/verizon-x-uidh


IPv6 and CGNAT growth has finally started to suppress IPv4 prices. There was a huge pump when hyperscalers decided they needed more. But IPv6 keeps growing and is the majority of traffic in many networks. If you own significantly more IPv4 addresses today than you need, I would dump them on the market yesterday. Spend some of the profits to move to IPv6 if still needed.


Well but then attackers just compile a kernel with a rootkit that hides the hack and itself from the APIs of the BPF program, so it has to deal with that too or it's trivially bypassed.

Anticheat and antivirus are two similar but different games. It's very complicated.


The bpf api isn't the only telemetry source for an anti cheat module. There's a lot of other things you can look at. A bpf api showing blanks for known pid descendent trees would be a big red flag. You're right that it's very complicated but the toolchain is there if someone wanted to do the hard work of making an attempt. It's really telemetry forensics and what can you do if the cheat is external to the system.


I'm surprised curlx_strcopy doesn't return success. Sure you could check if dest[0] != '/0' if you care to, but that's not only clumsy to write but also error prone, and so checking for success is not encouraged.


I guess the idea is that if the code does not crash at this line:

    DEBUGASSERT(slen < dsize);
it means it succeeded. Although some compilers will remove the assertions in release builds.

I would have preferred an explicit error code though.


assert() is always only compiled if NDEBUG is not defined. I hope DEBUGASSERT is just that too because it really sounds like it, even more so than assert does.

But regardless of whether the assert is compiled or not, its presence strongly signals that "in a C program strcpy should only be used when we have full control of both" is true for this new function as well.


Yeah, thought the same. Expect some CVEs in the future.


What kind of CVE would you expect? The destination buffer will always contain a valid null-terminated string (as long as the buffer size is not zero).


This is especially bizarre given that he explains above that "it is rare that copying a partial string is the right choice" and that the previous solution returned an error...

So now it silently fails and sets dest to an empty string without even partially copying anything!?


The latest DLSS and FSR are good actually. Maybe XeSS too.


This used to be a feature to protect spinning hard drives. Why this would exist today and why it would throttle anything is bizarre.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: