Related/funny: three years ago, someone found exactly such a bug because it was exploited against a Minecraft server they were running in screen (probably without the perpetrator understanding the root cause): https://lists.gnu.org/archive/html/screen-devel/2021-02/msg0...
> Is the syntactically correct dummy value the same each time? If so, how does that lead to new coverage?
Per my understanding, the dummy value is constant but is only used once (to create the first valid TLV). Everything after that is a mutation of the original value that, due to the custom mutator logic, is a valid TLV. The mutations are where new coverage comes from.
> In any case, why bother with this "if invalid replace with dummy" step? Why not generate/mutate a valid TLV value from the start?
I'm guessing to handle both when there are seed files that are already valid (which you'll want to use instead of a dummy value), and when there aren't any valid seed files.
Since a WireGuard peer only responds to cryptographically authenticated packets and UDP is connectionless — you don't get confirmation at the transport layer by way of a handshake or anything — WireGuard ports are invisible to you unless you own a private key whose corresponding public key is already approved by the peer.
> Signal is very proud that once a long time ago the state came to them asking for user data and signal could only tell them they had no data to provide.
Have you looked at https://signal.org/bigbrother/ recently? There are five instances of this, one as recent as November 2021.
Signal has the data being requested but they'd have to brute force a user's pin or use an exploit to get to it. Routine requests aren't going to compel them to take those actions and national security letters aren't going to be published on their website.
You can listen to tapes from his teenage years in the late 50s, where he's singing in almost that exact early 70s croon. But his voice throughout most of the 60s was very different and, for the most part, intentionally so.
But you can take your device off the network when running the password manager to ensure it isn't able to do that, for example. (Or more realistically, you can watch with something like Little Snitch or WireShark to ensure it isn't happening.) That's something you can't do when the password manager requires the network to do its main function.
It's absolutely incredible to me that people ignore one of the biggest sides of the argument for pre-baked, user friendly products like 1Password: usability for as many people as possible.
You're trusting the client whether or not it can talk on the network. A malicious update that starts generating predictable passwords for websites doesn't need a network connection.
I looked it up on wikipedia. But it was like learning monads from wikipedia. It's a dense nest of jargon that just leaves me wondering which way is up if I spend more than a few minutes following links.
