One of the things I hate about open-source is the paranoia that this "pull request" containing a useful update to my code is actually a trojan vuln/backdoor. github.com/robertdavidgra…
This sounds like a really useful feature, but at the same time, is enough code I can't simply press the "accept" button to accept the changes.
I'm tweeting about this because there are legal concerns. Whenever I talk to law enforcement, they demand it's my responsibility to verify that contributors aren't just adding code to help illegal activities.
In other words, demanding I do something like a "background check" for every pull request. Of course, not that far, but would would be the equivalent? In case, I briefly check their github account.
Looks very much like a fellow nerd in cybersec. On the other hand, if this where a North Korea sponsored hacker working to heist $billions from banks, well, they can also look like this.
Anyway, pull request accepted, the code is now updated, and the feature looks really useful and I'm kicking myself for not adding it sooner.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The solutions to your problems may involved "cloud" thingies, incidentally, but a cloud thingy is not the solution to your problems. Those pushing "cloud" thingies as the forefront of their solution to your problems, e.g. Brad Smith, are pushing, well, snake oil.
It's like that recent municipal water "hack". Nobody knows what happened, or even if it was a "hack". Yet everyone is promoting their solutions to the problem.
If you are promoting a solution and can't tell me how the hack happened, then your solution to the "hack" is snake oil.
I need to dribble out JSON output a few times second, each looking like {stuff}. How should I do it:
[
{stuff},
{stuff},
...
]
or:
{stuff}
{stuff}
{stuff}
...
In other words, a single item that if redirected to a file, would parse as JSON, even though it's meant to be read live. Or as a series of independent JSON objects?
Thanks the twitters! My answer is #2. I changed the option in the code to say "--ndjson-status" to communicate what's going on. Here are the two references people pointed me to: jsonlines.org ndjson.org
It's always "them" who don't understand, not "us". "We" have the clue, "they" don't.
In fact, it's this person who doesn't understand climate change. That's why deniers exist -- while climate change is real and important, those on the other side still misrepresent it.
It's like being correct that God exists -- and then claiming thus anybody who disputes "indulgences" is a heretic and must be excommunicated as a denier. No, Martin Luther believed in God, he just didn't believe in the excesses of the church.
No, climate change doesn't make everything worse. On average, 50% of changes are for the better, 50% are for the worse. The idea that climate change can only make things worse is so statistically improbable as to automatically be rejected by serious people
If this sounds like a wackjob conspiracy theory, it's because this is a wackjob conspiracy theory. Signal's source code and algorithms are open. Just because some government departs have given it funding doesn't mean it's a secret plot by the CIA.
Signal uses well-known crypto algorithms. If they are insecure, well, then all cryptography is insecure and it doesn't matter which encrypted messaging app you use.
If there's a backdoor in the code, well, the code is open source and people would be able to find it.
Here's is the "censorship episode" of the show "WKRP in Cincinnati", where you see Andy (radio station program director) argue "free enterprise" against preacher "Dr. Bob Hallier" who is using boycotts to get them to remove music from the radio:
Most of what you know of the 1980s hacking scene wasn't Internet, but "phone phreaking" and "BBSs". I don't know much about those things. I was an Internet hacker instead -- on the net since back before DNS was a thing (when 'hosts.txt' was distributed by hand).
By the late 1980s, computers from Sun Microsystems were a big deal. Yet, Sun (and other manufacturers) were immune to notifications of vulnerabilities. Issues had to be handle by tech support, and if you didn't have a support contract, you didn't matter.