It's equivalent to uploading someones PGP key to a keyserver without his or her permission.
128 karma · joined May 24, 2014
It's equivalent to uploading someones PGP key to a keyserver without his or her permission.
I hope fetchmail makes its choice too and dies. End of story.
Good point; How does one view the resulting react-page anyway? CTRL+U shows <body><script.../></body> no matter what state the SPA is in..
I see some interesting things like the surbl module but other than that this seems to be more like mimedefang (or that's at least what I've picked up from the landing page).
Also do you consider supporting multiple database drivers or will you stick with sqlite3?
- mixing unencrypted with encrypted data (why encrypting object files during bulk builds?)
- file-based, encrypted backups for free (including incremental jobs!)
- passwords/keys per directory
- passwords/keys per user
- passwords/keys per group
- (...)
People who like encfs/cryptfs will probably like this too.Defenders of current system for acquiring and and revoking TLS certificates have recent chafed in response to statements from this author that it's hopelessly broken. Besides remembering that almost all of these critics have a strong financial interest in the way the system works now
"chafed" because of this:
https://twitter.com/ivanristic/status/578536108662861824
So Ristic working for ssllabs automatically disqualifies him from asking the perfectly valid question "What is a better approach, in your opinion?"..
You still like your Goodin, tptacek? ;)
And with respect to the PGP-user / character link.. this is just beyond stupidity.
"Way to take a dump on people who make an effort."
And given that nowadays Green seems completely consumed by twitter while Moxie believes in fixing whatsapp, I wouldn't hold my breath.
Some algorithms and parts of the protocols as used by the 20 years old PGP-2 software are meanwhile considered unsafe. In particular the baked in use of the MD5 hash algorithm limits the security of PGP-2 keys to non-acceptable rate. Technically those PGP-2 keys are called version 3 keys (v3) and are easily identified by a shorter fingerprint which is commonly presented as 16 separate double hex digits.
With GnuPG 2.1 all support for those keys has gone. If they are in an existing keyring they will eventually be removed. If GnuPG encounters such a key on import it will not be imported due to the not anymore implemented v3 key format. Removing the v3 key support also reduces complexity of the code and is thus better than to keep on handling them with a specific error message.
There is one use case where PGP-2 keys may still be required: For existing encrypted data. We suggest to keep a version of GnuPG 1.4 around which still has support for these keys (it might be required to use the --allow-weak-digest-algos option). A better solution is to re-encrypt the data using a modern key.
https://gnupg.org/faq/whats-new-in-2.1.html
This only affects data encrypted by PGP-2, the original Phil Zimmerman PGP. If you are on GPG 1.4 or 2.0 and want to switch over to 2.1 this shouldn't be a problem.
Edit: see quoted text above.
My main issue with the article was the way he presented the story as if it was based on facts instead of a few unproven claims. Subsequently, the story spread to other non-technical platforms, re-reported as fact.
> Robert Graham (...)
Well, that doesn't really matter.. extraordinary claims were made in the complete absence of extraordinary proof. And then a multi-page story was written based on nothing.
> I think Green is being a bit unfair to GPG in this piece
I agree, his comments were slightly smug.
If it's from Goodin, you should always take it with a teaspoon of salt. He is often in way over his head with certain subjects he decides to write about, best example being BADBIOS, the story about a hearsay BIOS uber-virus. Made everybody shit their pants for days (even the MSM picked it up) and after weeks of waiting, the swarm of curious FW/BIOS analysts that were demanding dumps from Goodins source finally declared the story BS.
That aside, the following paragraph alone says a lot about Goodin's ham-handed journalism:
Still, it's not clear whether it makes sense to dump massive amounts of cash to refurbish code in such disrepair.
I glimpsed over the 1.4 branch for a few minutes (I bet longer than Goodin) and while some parts look complicated, it is not remotely as ugly as for example fetchmail or certain parts of the glibc.
Fexofenadine (Allegra, Telfast..):
"Unlike older antihistamines, fexofenadine does not have anticholinergic activity." http://www.medscape.com/viewarticle/406437_3
Bilastine (Bilaxten):
"No anticholinergic adverse events were observed in the clinical trials.." http://en.wikipedia.org/wiki/Bilastine
"bilastine's safety profile is satisfactory, since it lacks anticholinergic effects" http://www.ncbi.nlm.nih.gov/pubmed/22149338
Ugh.. can someone please tell me who started this ZFS-ECC-UBER-RAM fetish? Whenever I read anything about ZFS, some gollum first has to scream at me how superimportant a ridiculous amount of ram (especially ecc-ram) is. Why? Who said so? When?
I was hoping to read some recommendations on chipsets that are able to monitor multiple channels simultaneously.. but then it was just another misleading headline.
Again, untested:
#! /bin/sh
timeout=5
fifo=/tmp/discover-vnc.fifo
rm -f $fifo
mkfifo $fifo
dns-sd -B _rfb._tcp >$fifo &
pid1=$!
while read line; do
case $line in *_rfb._tcp.*)
# do something here.. then test
# if flag=3 and break otherwise
esac
done <$fifo &
pid2=$!
sleep $timeout && kill $pid1 $pid2 &
pid3=$!
wait $pid2
kill $pid3
It's also rather ugly to create a named pipe for this purposeBecause it creates a file in /tmp? Who cares? The alternative is bash voodoo magic.. the same magic that gave us shellshock.
$ bash --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
Copyright (C) 2007 Free Software Foundation, Inc.
$ : & echo $!
[1] 329
329 #! /bin/sh
fifo=/tmp/discover-vnc.fifo
rm -f $fifo
mkfifo $fifo
dns-sd -B _rfb._tcp >$fifo &
pid=$!
while read line; do
case $line in *_rfb._tcp.*)
# do something here.. then test
# if flag=3 and break otherwise
esac
done <$fifo
kill $pid The dns-sd command is primarily intended for interactive use. Because
its command-line arguments and output format are subject to change,
invoking it from a shell script will generally be fragile. Additionally,
the asynchronous nature of DNS Service Discovery does not lend itself
easily to script-oriented programming. For example, calls like "browse"
never complete;
Second, "SIGKILL is too verbose, SIGINT is too soft".. how about SIGTERM? Its very likely that you're doing it wrong if you need to use -KILL in your scripts.Third, "[1] 58181 killed ./discover-vnc.sh --- It's crucial to suppress this line." again, if you think you must suppress this, you're doing it wrong. This shouldn't pop up in the first place.
Fourth, what about fifos and `$!'?
Fifth, why bash? Use the sh-subset.
etc.
It's cute that you managed to solve your problem but this is nothing more than an unreliable hack, pompously presented ("Taming non-terminating Bash processes", "Kill the children"..)
Remove two `a' characters of the current line:
fax;.
Note: no mode change necessary
Also, line editing in /bin/{,k,ba}sh -o vi without `ftFT;,' is a pain.
Because when OSX n+1 is released, it's immediately impossible to get any work done on OSX n?
I'm still on 10.6 and see no reason to upgrade.
But it's a cute tool, no question.
WRT shorter: Magic numbers don't just suck in programming.
Never.