121–130 of 263 posts
Earlier quoted context omitted.
Downloading a deb via a package manager is more secure. Downloading a deb, comparing the hash (or at least noting down the hash) would also already be more secure. But yes, that the run arbitrary scripts is also a known issue, but this is not the main point as most code you download will be run at some point (and ideally this needs sandboxing of applications to fix).
> Downloading a deb via a package manager is more secure. Not what I meant. Getting software into 5 different distros and waiting years for it to be available to users is not really viable for most software authors.
Earlier quoted context omitted.
I would say that Rust would be a better choice rarher than patching memory safety on top of C. But I think the reason for this is that most, if not all, cryptographic reference implementations are in C. So they want to use existing reference implementations without having to port them to Rust. IMO cryptographers should start using Rust for their reference implementations, but I also get that they'd rather spend their…
> IMO cryptographers should start using Rust for their reference implementations IMO they should not, because if I look at a typical Rust code, I have no clue what is going on even with a basic understanding of Rust. C, however, is as simple as it gets and much closer to pseudocode.
I say this as someone who has written cryptographic code that’s been downloaded millions of times.
Earlier quoted context omitted.
I would like to know as well. All that is public is that a couple of IETF apparatchiks want to ban him for criticizing corporate and NSA influence: https://web.archive.org/web/20250513185456/https://mailarchi... The IETF has now accepted the required new moderation guidelines, which will essentially be a CoC troika that can ban selectively: https://mailarchive.ietf.org/arch/msg/mod-discuss/s4y2j3Dv6D... It is very sa…
... if he thinks some WG is making a mistake and he's not welcome there (everyone else seems to be okay with what's happening based on the quoted email on the first link), then - CoC or not - he should then leave, and publicly post distance himself from the outcome. (Obviously he was never the one to back down from a just fight, but it's important to find the right hill to die on. And allies! And him not following RF…
The IETF is a global standards-setting organization, intentionally created without a membership structure so that anyone with the technical competency can participate in an individual capacity. This lack of membership ensures its position as the primary neutral standards body because participants cannot exert influence as they could in a pay-to-play organization where members, companies, or governments pay fees to set the direction. IETF standards are reached by rough consensus, allowing the ideas with the strongest technical merit to rise to the surface.
Further, these standards that advance technology, increase security, and further connect individuals on a global scale are freely available, ensuring small-to-midsize companies and entrepreneurs anywhere in the world are on equal footing with the large technology companies.
With a community from around the world, and an increased focus on diversity in all its forms, IETF seeks to ensure that the global Internet has input from the global community, and represents the realities of all who use it.
There is only one IETF, and telling dissenters to leave is like telling a dissenting citizen to go to another country. I don't think that people (apart from real spammers) were banned in 1996. The CoC discussion and power grab has reached the IETF around 2020 and it continues.
"Posting too many messages" has been deemed a CoC violation by for example the PSF and its henchmen, and functionally the IETF is using the same selective enforcement no matter what the official rationale is. They won't go after the "director" Wouters, even though his message was threatening and rude.
Earlier quoted context omitted.
Note that Fil-C is a garbage-collected language that is significantly slower than C. It's not a target for writing new code (you'd be better off with C# or golang), but something like sandboxing with WASM, except that Fil-C crashes more precisely.
From the topic starter: "I've posted a graph showing nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4). Typically code compiled with Fil-C takes between 1x and 4x as many cycles as the same code compiled with clang" Thus, Fil-C compiled code is 1 to 4 times as slow as plain C. This is not in the "significantly slower" ballpark, like where most inter…
Earlier quoted context omitted.
s/webserver/DNS/
HTTPS is there, so you go down to that level only if you want to distrust any element of the public key infrastructure. Which, to be fair, there are plenty of reasons if you are paranoid -- they do tell you who's doing what in a shady way as they revoke, so there's a huge list of transgressions.
Earlier quoted context omitted.
> How do people think JavaScript works? Very slowly. Java, OCaml, or LuaJIT would be better examples here!
How many of the "GC is always slow" people would recognize those systems? Besides: V8 and JSC have pretty decent JITs nowadays. IME, performance of JIT systems has more to do with the structure of programs written in JS than with VM performance itself.
Fil-C: A memory-safe C implementation - https://news.ycombinator.com/item?id=45735877 - Oct 2025 (130 comments)
Safepoints and Fil-C - https://news.ycombinator.com/item?id=45258029 - Sept 2025 (44 comments)
Fil's Unbelievable Garbage Collector - https://news.ycombinator.com/item?id=45133938 - Sept 2025 (281 comments)
InvisiCaps: The Fil-C capability model - https://news.ycombinator.com/item?id=45123672 - Sept 2025 (2 comments)
Just some of the memory safety errors caught by Fil-C - https://news.ycombinator.com/item?id=43215935 - March 2025 (5 comments)
The Fil-C Manifesto: Garbage In, Memory Safety Out - https://news.ycombinator.com/item?id=42226587 - Nov 2024 (1 comment)
Rust haters, unite Fil-C aims to Make C Great Again - https://news.ycombinator.com/item?id=42219923 - Nov 2024 (6 comments)
Fil-C a memory-safe version of C and C++ - https://news.ycombinator.com/item?id=42158112 - Nov 2024 (1 comment)
Fil-C: Memory-Safe and Compatible C/C++ with No Unsafe Escape Hatches - https://news.ycombinator.com/item?id=41936980 - Oct 2024 (4 comments)
The Fil-C Manifesto: Garbage In, Memory Safety Out - https://news.ycombinator.com/item?id=39449500 - Feb 2024 (17 comments)
In addition, here are the major related subthreads from other submissions:
https://news.ycombinator.com/item?id=45568231 (Oct 2025)
https://news.ycombinator.com/item?id=45444224 (Oct 2025)
https://news.ycombinator.com/item?id=45235615 (Sept 2025)
https://news.ycombinator.com/item?id=45087632 (Aug 2025)
https://news.ycombinator.com/item?id=44874034 (Aug 2025)
https://news.ycombinator.com/item?id=43979112 (May 2025)
https://news.ycombinator.com/item?id=43948014 (May 2025)
https://news.ycombinator.com/item?id=43353602 (March 2025)
https://news.ycombinator.com/item?id=43195623 (Feb 2025)
https://news.ycombinator.com/item?id=43188375 (Feb 2025)
https://news.ycombinator.com/item?id=41899627 (Oct 2024)
https://news.ycombinator.com/item?id=41382026 (Aug 2024)
https://news.ycombinator.com/item?id=40556083 (June 2024)
https://news.ycombinator.com/item?id=39681774 (March 2024)
Earlier quoted context omitted.
I agree. The main advantage of Fil-C is compatibility with C, in a secure way. The disadvantages are speed, and garbage collection. (Even thought, I read that garbage collection might not be needed in some cases; I would be very interested in knowing more details). For new code, I would not use Fil-C. For kernel and low-level tools, other languages seem better. Right now, Rust is the only popular language in this spa…
> disadvantages are speed, and garbage collection. And size. About 10x increase both on disk and in memory $ stat -c '%s %n' {/opt/fil,}/bin/bash 15299472 /opt/fil/bin/bash 1446024 /bin/bash $ ps -eo rss,cmd | grep /bash 34772 /opt/fil/bin/bash 4256 /bin/bash
For those who might miss it, the notes cite a new 64-bit version of cdb that supports exabyte databases https://cdb.cr.yp.to Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve
This is not correct. There isn't a cdb subdomain because cdb.cr.yp.to doesn't have NS records, which is where DNSCurve fits in. If you have a DNSCurve resolver, then your queries for cdb.cr.yp.to will use DNSCurve and will be sent to the yp.to nameservers.
From there, if you have pqconnect, your http(s) connection to cdb.cr.yp.to will happen over pqconnect.
Maybe the confusion is because both DNSCurve and pqconnect encode pubkeys in DNS, but they do different things.
Here is DNSCurve:
$ dig +short ns yp.to
uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
$ dig +short cdb.cr.yp.to
pq1htvv9k4wkfcmpx6rufjlt1qrr4mnv0dzygx5mlrjdfsxczbnzun055g15fg1.yp.to.
131.193.32.108