As a test on various distros, I ran
iconv -l |grep 2022 |grep -i cn
and it listed ISO-2022-CN-EXT// and ISO2022CNEXT// before I made any changes. After editing the modules and running iconvconfig the command no longer showed those charsets.
This was handy since the alma8 has a /usr/lib64/gconv/gconv-modules file but the file to edit was /usr/lib64/gconv/gconv-modules.d/gconv-modules-extra.conf
Thanks a bunch to you and thenickdude for the test command and config to change.
I have an old VPS that isn't worth trying to update to a newer OS image, because I'm already (slowly) migrating things off of it before the current paid-up term expires, but it definitely won't get the newer glibc. Disabling the vulnerable character encoding works for me, since no legitimate user of the server will need these conversion pairs.
i would be too worried that it would get triggered by accident or that someone would pretend to be me and hit the "panic button". i could imagine being on vacation and suddenly being locked out from all my stuff. it's bad enough when my bank card gets flagged.
i would be a bit worried about accidental passwords getting into the syslog. i have typed passwords out of habit when they were not required or before a remote system responds only to have the password end up as a bash command. i then have to go into the .bash_history file and remove them.
Agreed - folks who are logged in as root a lot seem to have an uncanny tendency to type all kinds of stuff that probably shouldn't show up in a log anywhere.
These tend to be the same folks who think that using "sudo" is a waste of time and serves no purpose. Not that I've ever accidentally rebooted a box, of course. :P
ground patrol cars or aerial surveillance require a person to operate them. GPS tracking allows for tracking many targets at once and then sifting through the data to find "bad guys".
the added costs of having a person track a target means more care is taken to avoid false positives. the person doing the tracking can also dis-regard irrelevant data that an automated system might erroneously use.
imagine some program that automatically sifted through a source of ubiquitous GPS data which actually did catch 100% of all terrorist attempts in New York in 2010 (the Times Square bombing attempt). what if that system meant 100 false positives were added to the no-fly-list because they drove on street X on date Y followed by street Z within 2 days (or some other such algorithm) when (if) someone asks about these no-fly-list additions they are simply told that the suspects exhibited behavior that was consistent with the Times Square bomber... if you are not a terrorist, you have nothing to hide!
GPS tracking allows for tracking many targets at once and then sifting through the data to find "bad guys".
Excellent point. Professional statisticians make these mistakes all the time. It is widely considered the reason that so much published scientific research is false. If professional statisticians make these errors, then how can we expect the average policeman not to?
The number of people the FBI can surveil with these devices is, while larger than the number of people they can tail in cars, still tiny. That's why I'm OK with it.
The number of people they could surveil with a court order for access to OnStar data is so great that I don't even think they should be able to get court orders for bulk access to OnStar data.
Eh, that's true, but at the same time, tiny is relative. For perspective: The low-end cost of commercial GPS tracking devices is about $50 (as determined by searching Amazon). Assuming the FBI can get a bulk deal on a tracker around that price point, it could track every single Muslim in America for less than its annual construction budget.
i think it says more about how simple real humans are when they interact with each other. as limited as Eliza is, it has worked many times. how many times a day have you had face-to-face interactions with people that are simply canned responses. i remember keeping a phone call going with high-school girlfriend by randomly responding with one of the following : "uh-huh", "yeah" or "really".
i agree with you that preserving anonymity is a valid goal. spending 20-30 minutes on the phone is not how one should run something like a whistle-blower's hotline.
i don't agree with the idea that you are "...being kind and generous by not exploiting...".
hardly. exploiting the vulnerability is clearly and objectively illegal. It is likely to affect not only the company itself but also any innocent customers one might defraud.
as i understand it, they were doing experiments to watch how neutrinos change between "electron", "muon" and "tau" flavors. the timing of when the neutrino was sent from cern and viewed by the experiment was required to match what the neutrino was before and after.
pick up a Logitech Wireless Solar Keyboard and a compatible mouse (like the M305) and they can both use the same USB receiver. plus, it's a solar powered wireless keyboard!
* you'll need to bind the mouse and keyboard to the same receiver on a windows machine before you connect it to your linux box until linux unifying support is available.
it goes without saying that a 17 year old series is more well known than a new game. on the other hand, i have never referred to "The Elder Scrolls" as just "Scrolls". i've called it "Morrowind" or "Oblivion" and i'll probably refer to the new game as just "Skyrim". if i saw a game that was just called "Scrolls" i would not confuse it with Bethesda's games.
I'm not saying you would, I'm saying PR wise Mojang and Notch have everything to gain from settling this matter of law in a game of Quake, while Bethesda has very little.
there might not be 17 trillion songs, but you aren't limited to the first 4 words of the song. there might be 100-300 words per song and you can pick your starting word anywhere you like.
But it falls into the same boat as any dictionary attack. Most people with a passphrase are probably going to use one from a song. 90% of them are going to use one of the top 1,000 songs, 90% of them are going to start at the beginning of a line. If we say there are ~20 unique lines in the average song, and most people won't use more than ten successive words even if it bridges a line, that's 1000 * 20 * 10 = a keyspace of 200,000. Trivial.
What this means is even if you decide you're going to be really secure and pick, say, the 30,000th most popular song, assume all songs have 200 unique lines (to account for sensical starting points in the middle of lines), and use 20 words from it, you're in a keyspace of only 120 million, which even if it takes 1ms to hash will be cracked in a day.
By contrast, four random english words chosen from the 2,048 most common has a keyspace of ~1.75e13, or 17,500,000,000,000.
Choosing a clever, unusual line from the middle of a very uncommon song is the passphrase land version of choosing a rare English dictionary word and replacing the vowels with numbers. If your hash gets compromised, it might as well be "password".
How is this an improvement? I now have to remember a song lyric, and some set of random manipulations of that song lyric. I've used that trick for passwords before, and it was a hassle. But that doesn't even matter— unless you're choosing the manipulations randomly (which is a contradiction in terms) you're falling right back into the exact damn trap the comic was about!
You've added ! at the end, replaced s with z, capitalized some words, and replaced vowels with numbers. These are already standard manipulations in a dictionary attack. And it's causing you to ignore the fact that you've chosen what is probably among the top 10 song lyrics used. "p4ssw0rd!" is "password" as far as a dictionary attacker is concerned. Calling this trivial to brute force is demeaning to the word "trivial". Your attacker wouldn't even laugh at you, because there'd be dozens of other hashes in the file just like yours.
It's been said over and over in these comments: the appearance of randomness is not randomness. Humans are horrible at making things random, as you've just demonstrated. Stop trying to make it look weird, and actually do the math.
It's fairly easy for me to remember those manipulations. But you're right insofar that this would probably be both safer and easier to remember:
Smells like teen spirit, and I like that plenty mucho!
I'm too lazy to do the math on it, perhaps you can help out?
Edit: It's a little annoying to collect these downvotes from people who either haven't done the math themselves or are too lazy to explain their advanced attack methods.
In my naive opinion my string above is at least equivalent to a 12 character password from a set of "Mixed upper and lower case alphabet plus numbers and common symbols.".
I count each word (10) and both symbols (,!) as a character here.
According to [1] an 8 char password of that type would take 83½ Days to crack in a Class-F attack ("supercomputer"). I'm purely guessing that those additional 4 "chars" should put it well into the multi-year range, under the premise my other assumptions are not too far off and that the number of english words is quite a bit larger than the number of ascii characters/symbols.
Any of the downvoters care to debunk that with real math?
I'd be honestly curious about a worst-case analysis that assumes the fragment "Smells like teen spirit" does appear in the attackers dictionary.
Yeah, that's what I was getting at. Something like that is pretty much immune to naive brute force, even if we count "Smells like teen spirit" as a word. My guess would be that if it does get cracked, it would be by searching [lyric]+", and"+[some kind of Markov attack], but I honestly have no idea how one would work out the entropy in that model. It depends a lot on how the search is carried out, I think.
I guess we'll find out when passphrases become common :)
and it listed ISO-2022-CN-EXT// and ISO2022CNEXT// before I made any changes. After editing the modules and running iconvconfig the command no longer showed those charsets.
This was handy since the alma8 has a /usr/lib64/gconv/gconv-modules file but the file to edit was /usr/lib64/gconv/gconv-modules.d/gconv-modules-extra.conf