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

A lot of Let’s Encrypt is not the software but a bunch of auditing and process that ensure compliance and make it legible to the required auditors.

I understand there's probably a big thorny problem of duplicating the corporate process/policies on the human level that ensure compliance, but is the back-end software pipelining stuff to CT logs not also something that can be replicated? Or is it not part of the server side stuff which has been open sourced?

https://letsencrypt.org/docs/ct-logs/


Our code for sending stuff to CT logs is fully open source. But that's the tiniest slice of our compliance regime -- the vast majority of it is things like audit logging certain events, preserving audit logs in specific ways for certain amounts of time, ensuring dual-controls on all systems, being both audited and penetration tested annually, maintaining firewalls and vulnerability scanning tools, etc.

It's absolutely possible to spin up another new CA; lots of folks have done so over the years. But having time, and money, and prior experience all help a lot.


That's the policy, but we've been a bit more conservative in practice. `main` currently targets 1.88, but that's only because a security issue in the time crate has forced our hand (one reason I don't like the time crate all that much). Before that, it was 1.83 (from November 2024). Our last release targets 1.71 (from July 2023).


I'd bet a supermajority of Swift commits comes from Apple developers. Pretty sure the rust-lang/rust commit authors would be much less centralized.



I think the way Rust checks borrows also makes it a lot more feasible to avoid allocations/copies; not because it is impossible to do in C, but because doing it in C requires writing very careful documentation and the caller to actually read that documentation. In (safe) Rust this is all checked by the compiler such that libraries can leverage it without blowing their complexity budget.


There’s also a compounding effect: I’ve heard from a hardware vendor that they spend a lot of time optimizing OpenSSL to get the most out of their silicon, so for their customers they suggest using OpenSSL to get the most out of the hardware.


How is the HiDPI situation, and font rendering? Last time I tried it on my M1 Max with Asahi it still looked substantially worse.


To quote one of the lead GTK/GNOME developers, "what makes you think font sharpness is a metric (of font rendering quality)"? It's absolute madness: https://gitlab.gnome.org/GNOME/gtk/-/issues/3787.


I'm pretty sure private PKIs are an option that is pretty straightforward to use.

Security is still a lot better because the root is communicated out of band.


When I asked about financial support, the Senior Principal Software Engineer from Mozilla I talked to said "Mozilla has no money".

To be fair, we've gotten a great amount of code contributions from the Mozilla folks, so it's not like they haven't contributed anything.

(I am one of the Quinn maintainers.)


It's always interesting how these large organizations can bring in tens of millions of dollars in excess of expenses, yet still manage to "have no money"

Source: https://assets.mozilla.net/annualreport/2024/b200-mozilla-fo...


It is true, Mozilla has no money (except for paying execs)


I would argue that regexes are often more complex than simple parsers.


That's where the familiarity factor steps in.


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

Search: