ericseppanen

This is so true.

The idea that a program can approach some optimal bug-free state, never to be modified or refactored again, doesn't resemble any project I've ever encountered.

"we model a scenario where the original code is memory-safe; the ported code is memory-safe; and we consider memory safety and undefined behavior that may arise across the FFI layer between the two pieces of code."

I may be stating the obvious, but that's a bit of a strawman. Yes, writing good FFI code is hard; yes it could result in security/soundness issues; yes, we could use better tools in this space.

But nobody rewrites C code in Rust if they believe existing codebase is free of memory safety hazards; they rewrite it because they think the result will contain fewer hazards, even accounting for the potential problems at the FFI boundary.

If I could remove tens of thousands of lines of hard-to-analyze C code, and replace it with tens of thousands of lines of safe Rust, paired with a few hundred lines of hard-to-analyze FFI adapters, that sounds like a pretty good tradeoff to me. I now know exactly where to focus my attention, and I can have confidence that the situation will only improve with time: better tooling may allow me to improve the dangerous FFI layer, and in the meantime I can recklessly improve the safe Rust module without fear of introducing new memory unsafety bugs, unsound behavior, or data races.

I don't think this is true in the general case. Most Solokeys come in a "locked" form-- they will only accept firmware updates that are signed by the manufacturer. You can buy a "hacker" variant that is unlocked (meant for those that want to tinker with the firmware), but if you were to use one of those you're giving up security against someone loading malicious firmware onto your device.

This is probably the right tradeoff for most users. Solokeys has done a great job of providing continuous support for all of their products, and their software stack has been open source since the beginning. That (combined with the low price) makes them my first choice for a hardware security token.

I can confirm that on Sonic (resold AT&T) VDSL I am seeing this exact corruption.

Nice find! I had been wondering why I had been seeing odd TLS failure messages recently.

For those that enjoy stories about the early days of electric guitar, I recommend picking up the book "The Birth of Loud: Leo Fender, Les Paul, and the Guitar-Pioneering Rivalry That Shaped Rock 'n' Roll" by Ian S. Port. It's a great story about the first electric guitars and their creators.

Print it on a shirt, and you have the thing William Gibson dreamed up in "Zero History":

"What’s that?" she asked.

"The ugliest T-shirt in the world," he said… "So ugly that digital cameras forget they’ve seen it."

It's interesting that their ssh-agent runs as a service under an Administrator account. I'd guess this is an attempt to better protect the private key against theft during a local compromise (i.e. unlocked computer left running on your desk).

I haven't seen this done on Linux. Has this trick been implemented on other systems?

regarding "development job... putting me outside the income level":

I faced the same situation; after being rejected, all I had to do was file some extra paperwork ("special circumstances") saying that I'd left my job and no longer had any income.

The time investment to prove or disprove this statement is more than I'm willing to give. I'd prefer to spend my time working with projects whose maintainers aren't hostile to my privacy.

"Each Bitwarden installation requires a unique installation id and installation key."

Sorry, it doesn't count as open source if everyone needs your permission to run it.