New on blog: "The perils of transition to 64-bit #time_t"

"""
In the "Overview of cross-architecture portability problems", I have dedicated a section to the problems resulting from use of #32-bit `time_t` type. This design decision, still affecting Gentoo systems using glibc, means that 32-bit applications will suddenly start failing in horrible ways in 2038: they will be getting `-1` error instead of the current time, they won't be able to `stat()` files. In one word: complete mayhem will emerge.

There is a general agreement that the way forward is to change `time_t` to a 64-bit type. Musl has already switched to that, glibc supports it as an option. A number of other distributions such as Debian have taken the leap and switched. Unfortunately, source-based distributions such as #Gentoo don't have it that easy. So we are still debating the issue and experimenting, trying to figure out a maximally safe upgrade path for our users.

Unfortunately, that's nowhere near trivial. Above all, we are talking about a breaking ABI change. It's all-or-nothing. If a library uses `time_t` in its API, everything linking to it needs to use the same type width. In this post, I'd like to explore the issue in detail — why is it so bad, and what we can do to make it safer.
"""

https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/

Them: “This is not a paywall.”
Me: “whew”

Them: Provide your Email address”

Me: “that’s a payment, though. Personal information is a payment”

Analog filters, part II: let it ring

https://lcamtuf.substack.com/p/analog-filters-part-2-let-it-ring/?1

If you feel like joining the “fun”, here’s the javadoc for #Ghidra Version Tracking:

https://scrapco.de/ghidra_docs/Features/VersionTracking/javadoc/

(I had to update my script again to include this - digging up docs for NSA sw really has some Quest for Knowledge vibes…)

@wendynather and 2 slides into "how to fix it", I've quoted you

Again, really hoping they record your talk, so I have some new quotes from when I update these slides 😅

I’m happy to see that the GOV.UK Service Manual’s “Building a robust frontend using progressive enhancement” page was updated this week and made it to the top of Hacker News today. The technology industry would collectively save unimaginable quantities of time, money, energy and stress if this single page were required reading for everyone involved in building a web site. https://www.gov.uk/service-manual/technology/using-progressive-enhancement

#patchfriday on #cups #vulnerabilities

https://patchfriday.com/158/

@jeffvanderstoep Thanks for your reply! I don’t doubt the validity of your measurement. I’d argue about two things:

• The simpler thing is communication: the phrase “half-life” or “decay” implies that vulns disappear without explicit dev intervention, e.g. as a side-effect of unrelated code changes (or even the passage of time!). While this may be true in some cases I don’t see how the data would (or could) support such an observation.
• My understanding is that when we look at overall results of different vuln discovery strategies (your study) or applying the same strategy with “more force” (Böhme-Falk) we basically see the effects of testing coverage, and it’s no surprise we can grow coverage faster in new code. What I think would be more revealing is looking at new vulns(/LoC?) vs code age when a new discovery method (e.g. a new sanitizer or more intelligent test-case generation ) is introduced. FTR: I bet such data would actually confirm your results, but without data about the effect of new discovery methods I think drawing conclusions about code “maturity” is much harder.

"Sometimes, hacking is just someone spending more time on something than anyone else might reasonably expect.”

— Jerry Gamblin

40th Weekly Vuln Research newsletter is OUT NOW 📰

iOS kernel exploitation from @alfiecg_dev

Elgato hacking from @dt_db

@_tsuro bypasses CET

RCU Internals from @u1f383

Google Teams check off their OKRs

➕ Jobs and more 👇

https://blog.exploits.club/exploits-club-weekly-newsletter-40-ios-kernel-exploitation-cet-bypasses-elgato-hardware-repair-and-more/