What you're proposing sounds like Kamouflage (PDF link from TFA), with only 1 decoy password set (Kamouflage suggest 10,000); and suffers from the problem of generating plausible fake master passwords without revealing anything about the real master password, as mentioned by the authors of NoCrack.
What the NoCrack authors try to achieve is a solution where every incorrect guess at the master password still provides a set of (incorrect but at least sometimes plausible) passwords. A bit like a one-time pad, which is the only provably secure encryption, because brute-forcing the key yields all the possible plain texts (both the correct and all the incorrect ones). Of course, the problem with the one-time pad is that the key length matches the plain text length, which would completely eliminate the benefit of a password manager. Additionally, as noted in TFA, authorized users might not like the idea that making a typo when entering the master password yields (seemingly) correct passwords.:-)
I'm not convinced the NoCrack authors have actually succeeded, as they claim, but can nevertheless recommend the NoCrack paper (PDF), since it discusses pros of cons of the approach and alternatives.
ES said that if my gmail account was moved overseas on an international server, then the NSA could have a copy of my account even if there were no international sources/targets. Is that true or false?
That's true. While theoretically the NSA is not allowed to monitor communications between two american citizens, in practice, any communication leaving the country is simply assumed to involve a foreigner and is thus up for grabs. This "inadvertent" capture of american communications is in fact standard operating procedure:
The government has set a dismally low bar for concluding that a potential surveillance target is, in fact, a foreigner located abroad. By default, targets are assumed to be foreign. That's right, the procedures allow the NSA to presume that prospective targets are foreigners outside the United States absent specific information to the contrary—and to presume therefore that those individuals are fair game for warrantless surveillance.
It differs from e.g. the US system in a number of ways:
* It's run by an independent government-sponsored organization, not the industry.
* For children not accompanied by an adult, the highest rating is "15 and older".
* Children ages 7 and up can see any movie if accompanied by an adult, no matter the rating.
* The board is charged only with determining if a film could be psychologically damaging to a typical child. They do not judge the "morals" and message of the film.
* The board features actual child development experts. As such, they know that cursing and nudity is not harmful to children, and if that's all the film contains, it will be rated "All audiences".
Denmark: 7+ recommended (but all ages admitted) due "strange and threatening persons, assaults, fights and accidents [...] all in a comedic context" (a context which could be lost on very young children).
The Media Council classifies films based on a perspective purely concerning harmfulness. The classification decision shall be made on the basis of an assessment of whether a film is considered harmful for children in that particular age group. When classifying films, we look at film effects, depictions of grievous loss, degree of realism, possibility of identification, inclusion of redemption within the course, genre and the expected media competences of the age group in question.
The Media Council’s view on child protection is that
* Children can manage a good thrill.
* Children are not likely to fall to pieces by the slightest push.
* Children are active users of media and, therefore, already in an early age, they have accumulated both media competencies and experiences.
* Media are good resources in children’s everyday life.
* It is acceptable that films frighten, though, only to a certain limit. The Media Council sets these limits.
we havnt even fixed the train crash issues yet... and how hard could that be:)
Not that hard. Automatic train operation is a solved problem; a properly installed, modern ATO system is safer than the best human driver, better at following time tables, and even has significantly lower energy consumption. In fact, many ATO mass transit lines cannot be run manually (without cutting down on the number of departures); human drivers are not able to keep up with the amount of traffic managed by the ATO.
An ATO will not stop the train if there's an unregistered person or vehicle on the tracks (or if the tracks are gone entirely, e.g. due to flooding). But then, the braking distance for a passenger train at speed is high enough that a human won't be able to stop it either.
Also, ATO systems may have a higher false-positive rate than manual systems... e.g. stopping the train because an umbrella has fallen on the tracks (to take a concrete example from the Copenhagen Metro). But that's an availability issue, not a safety issue. (And as noted, humans aren't able to keep up during normal operation, so the ATO still wins on availability overall.)
See what happened in Paris and Denmark. People from Europe travel to Syria and Iraq to fight with ISIS, get training and AK47s, and then come back to Europe to kill the infidels.
Omar El-Hussein, the Copenhagen shooter, never went to Syria nor Iraq, never received any terrorist training, and didn't use an AK47, nor is there any evidence he ever communicated with terrorist organisations.
He did use a C7 rifle stolen from a member of the Danish national guard, but apparently had no weapons training. He did spend a couple of years in the Middle East years ago, but his radicalization appears to have happened primarily while he was incarcerated in Denmark.
Can they do it with corporate code where there are naming and style standards in abundance, and code reviews to ensure those guidelines are followed?
Presumably, yes. Style guides are 95% formatting, and if one RTFA (I know, I know), they look only at the structure of the parsed AST, not variable names, comments and whitespace. From the article:
Accuracy rates weren’t statistically different when using an off-the-shelf C++ code obfuscators. Since these tools generally work by refactoring names and removing spaces and comments, the syntactic feature set wasn’t changed so author identification at similar rates was still possible.
Since they look at code structure, they've even found identifying patterns that survive compilation and end up in the binary.
This is one of the coolest data mining results I've seen in quite a while.
How would the West feel about the release of a popular film in which the assassination of a living head of state is planned? How would your government behave toward you if YOU wrote a book / published a film / performed a play about this?
In 2006, Death of a President portrayed the assasination of George W. Bush. I don't remember hearing about it at the time, and even searching the website of Fox News doesn't turn up much controversy.
In 2008, AFR came out, in which Anders Fogh Rasmussen, the then-Prime Minister of Denmark (and later Secretary-General of NATO) was murdered (and also, incidentally, portrayed as a closeted homosexual, in line with long-standing rumours). It genereted minor controversy, was well-received by critics, and a failure at the box office. I found it forgettable (I literally don't remember any of it).
Of course, both films were small, independent films, and both can legitimately claim to use the controversial plot for a higher purpose. The Interview... not so much.
In addition to which, you replace it with something that requires more typing, and does not give any feedback.
service nfs restart
stopping nfsd
starting nfsd
etc.
The very first thing out of his mouth is a straw man.
+1 Basically, his arguments are :
* systemd haters have no clue about UNIX
* RedHat took a long time to notice my genius
* Gentoo users are old-farts that don't like beautifully written shiny new stuff
* Debian users are even older assholes
* You can use Gnome without systemd, but it won't work
* I listen to users, but they're all idiots
I take it that the irony of accusing Lennart of strawman arguments and then posting this is lost on you.
Solar is the real eye opener and should serve as a lesson on blindly trusting hype and "What seems obvious." Solar panels are terrible for the environment,
It's always important to remember that there's no such thing as free energy. That said, the linked graph doesn't say anything about solar being "terrible for the environment", only that other sources of electricity consumes* very little silver compared to solar (as Scientific American also notes in the graph). Importantly, it does not show how that use compares to e.g. worldwide silver use.
* "consumes"? "wastes"? "produces as a byproduct"? Pretty sure that oil energy (or biomass!) doesn't consume uranium, even if drilling for oil produces it as a byproduct. Not sure what exactly is being graphed here, honestly. Unfortunately, the cited report is paywalled.
Anyway, if you look at the other report cited by Scientific American as the graph source, in figure 4 on page 19, it shows the global material requirements (in giga-grams, that is, kilotons) under various energy mix scenarios. Neither silver or tin use even registers on the graph in the so-called "non-fossil" scenario (mix of solar, wind and hydro - and no nuclear). In other words, in the "non-fossil" scenario, silver and tin usage for power is less than 1 kiloton a year. Worldwide silver use in 2013 was 34 kt.
As a bonus, silver recycles better than aluminum, with energy savings of 96% (table 4.4).
It seems whenever people want to show how simple a SysV init script can be, they pull out examples that don't do half of what the (still much shorter) SystemD unit file does.
In this example from Slackware:
- 'sendmail' is a globally reserved name for a binary; only the system-wide sendmail daemon may use it.
- you cannot query the service status.
- there's no automatic preprocesing of sendmail config files (rehashing etc.)
- there's no dependency information
And that's just what's missing compared to the Fedora SysV init script.
The Fedora SystemD unit file adds at least the following features:
- the ability to reliably stop or restart the service
- automatic restart if the service dies
1.6M? The U.S. prison population is 2,266,800 according to Wikipedia. It's been over 2M for years, and was 2,418,352 in 2008.
In the U.S., the word "prison" is more specific than you think. Look at the third figure from the top at your own link.
In 2010, the U.S. prison population was ~1,518,000 (state and federal prisons). The U.S. jail population was ~749,000. The sum of those is 2,267,000; then comes another ~90,000 in juvenile detention (see the table below the figure). Add all these (and a bunch of smaller numbers, such as holding facilities for immigrants, and military facilities), you get the number of incarcerated people, which is the number you mention.
But yes, AFAIK the U.S. still incarcerates more people than any other country in the world, both as a fraction of the population, and in absolute numbers. There's a long way down to the next on the list.
Enh, seems to be only off by a factor 10, though IANAEE (I am not an electrical engineer). Forgive me if I'm missing a factor 1.44 or something, below.
Obviously you don't charge an electric car battery at 12 V. What the individual cells do is irrelevant, since they charge in parallel; the bottle neck is the cable attached to the car (and cooling, but hey, we're assuming magic new wonder battery tech, so I'll conveniently ignore that issue).
The highest power available using standard CEE (IEC 60309) plugs and mainline voltage is 3 x 125A x 230V, or about 86 kW. This is not normal in a home, obviously, but you can easily get a couple of these in commercial installations.
Ignoring losses (I know, I know), 86 kW means one hour to fully charge a Tesla Model S with the big 85 kWh battery pack, but that's also a big battery pack.
Charging the 48 kWh battery of the upcoming Model E to 70 % will take: 70% x 48 kWh / 86 kW = 23 minutes.
Now, I would've thought 3 x 125 A x 230V was about the limit, simple due to the weight (those cables are very heavy!). But apparently, Tesla Superchargers go beyond this, to more than 120 kW (340 A x 360 V), with possible plans for 135 kW or even 150 kW. (I guess if the cable is short enough, and you increase voltage beyond mains voltage...) This gives you 70% x 48 kWh charging times in as little as 17 minutes (120 kW) or even 13 minutes (150 kW). Still a far cry from 2 minutes, but then the 17 minute figure is using current mass-market technology.
Yup, this is what you get when a short-sighted totalitarian government messes with the water cycle to enable farming in a desert, consequences be damned.
Come to think of it, California is what you get when a short-sighted democratic government messes with the water cycle to enable farming in a desert, consequences be damned.
Let's face it, environmental concerns wasn't really on any government's radar until the 70s. (And a lot of countries still try to ignore them...)
It really has nothing to do with the default shell. It won't matter what shell is the default when your CGI script starts with #!/bin/bash.
No, no, no, no... People really don't get the scope of this.
It doesn't matter what the default user shell is, or what language a CGI script is written in. Bash is the most common system shell, which means it's invoked all the time when other programs run commands.
Obviously, I can't know this, but OP is probably not using csh as his system shell, because that's not POSIX compliant and would cause major breakage.
If/bin/sh is Bash, you're vulnerable, no matter what shell you're using yourself, or what language your CGI script is written in.
Also, CGI scripts is only the most obvious attack vector; others that have been identified so far are the CUPS printing daemon, the ISC DHCP client and locked down SSH shells like those commonly used to host Git repositories. But there are without doubt many more. The only safe thing to do is to upgrade or remove Bash from your system immediately.
No, it is any CGI program that sets an environment variable to unchecked user input and then invokes a shell or calls any other program that invokes a shell.
Got that?
No, it's not the CGI program that sets the HTTP_USER_AGENT environment variable, and this is not a vulnerability in the CGI program nor the CGI protocol. The fault lies 100% with Bash, which executes arbitrary shell code from arbitrary environment variables.
For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)
Well for one most languages the equivalent facility is available and usually used since it is a requirement to scale.
I know, mod_perl and mod_wsgi on Apache, and of course, Fast CGI. But CGI is still common in a lot of setups.
For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.
Even if you don't call out to the shell yourself, the standard library might.
Pop quiz 1: How is the PHP mail function implemented?
Pop quiz 2: What parts of the Python standard library module uuid are safe to use, and what parts will render your CGI script vulnerable?
I guess I was wrong to play down the severity of bash, but my hope was for people to just consider themselves to make a mistake by ever potentially having bash in a cgi context, for reasons beyond this exploit.
It's the system shell. It's everywhere. The real lesson here is to not use a big bulky program like Bash as the system shell.
In those days [late 80s/early 90s] revision control wasn't universally used. Even as late as the early 00's I was training engineers coming out of master's degree IT programs who had no idea how to use a revision control system.
Linus didn't use a revision control system for the Linux kernel until 2002.
(Aw... comparisons between CVS and the "soon to be finished" Subversion. How quaint.)
Basically, this Bash bug is really only exploitable by remote users because of some questionable decisions made in designing the software stack.
Hm, no, the fault here lies squarely with Bash choosing to interpret an environment variable called HTTP_USER_AGENT as a program to execute.
This is not about accepting arbitrary environment variables; CGI puts data in a few, well-defined variables. This is a perfectly legimiate use of environment variables. (And Windows does the exact same thing.)
You're right that using a "full-bore shell program" such as Bash as the system shell is moronic. It is, unfortunately, still the norm on all major Linux distros except Debian and derivatives (which use the limited Dash shell, which is not vulnerable).
Primarily, I think this is a wake up call for Fedora, SUSE and the others: Bash is a huge, complex component, evidently with insufficient security review, and should not be used as the system shell. Debian dropped it for performance reasons, but now we can add security concerns to the list. It can stay around for use as an interactive shell (though why you'd do that when you have zsh, I don't know...)
Slashdot Mirror
What you're proposing sounds like Kamouflage (PDF link from TFA), with only 1 decoy password set (Kamouflage suggest 10,000); and suffers from the problem of generating plausible fake master passwords without revealing anything about the real master password, as mentioned by the authors of NoCrack.
What the NoCrack authors try to achieve is a solution where every incorrect guess at the master password still provides a set of (incorrect but at least sometimes plausible) passwords. A bit like a one-time pad, which is the only provably secure encryption, because brute-forcing the key yields all the possible plain texts (both the correct and all the incorrect ones). Of course, the problem with the one-time pad is that the key length matches the plain text length, which would completely eliminate the benefit of a password manager. Additionally, as noted in TFA, authorized users might not like the idea that making a typo when entering the master password yields (seemingly) correct passwords. :-)
I'm not convinced the NoCrack authors have actually succeeded, as they claim, but can nevertheless recommend the NoCrack paper (PDF), since it discusses pros of cons of the approach and alternatives.
Upfront cost? Most engines are charging percentages of revenue
Of the game engines mentioned in TFA, "most" = "one"?
Unity: $1500 (or $900/year) per developer.
CryEngine: $120/year per developer.
Source 2 (upcoming): Free (for games released on Steam).
Unreal: 5% royalty.
Some facts about the U.S. justice system:
* The Reid technique is widely used for interrogations, a technique notorious for its effectiveness in enticing false confessions.
* Only 5 % of convicted felons had their case tried in court; the rest make a plea bargain (typically under threats of excessively long prison sentences and/or the death penalty).
* Judges are elected, subjecting them to the whims of public opinion and making them more politicians than impartial legal officials.
* At least 4 % of people sentenced to death in the U.S. are innocent.
* The U.S. incarcerates more people than any other country in the world, not just relative to the population size, but in absolute numbers.
* U.S. private prisons sees $3+ billion in annual revenue... Not that that has anything to do with the above issues, I'm sure.
The U.S. justice system is broken in so many ways, I'm certainly forgetting some things.
ES said that if my gmail account was moved overseas on an international server, then the NSA could have a copy of my account even if there were no international sources/targets. Is that true or false?
That's true. While theoretically the NSA is not allowed to monitor communications between two american citizens, in practice, any communication leaving the country is simply assumed to involve a foreigner and is thus up for grabs. This "inadvertent" capture of american communications is in fact standard operating procedure:
The government has set a dismally low bar for concluding that a potential surveillance target is, in fact, a foreigner located abroad. By default, targets are assumed to be foreign. That's right, the procedures allow the NSA to presume that prospective targets are foreigners outside the United States absent specific information to the contrary—and to presume therefore that those individuals are fair game for warrantless surveillance.
The difference in philosophy [between Scandinavian and Anglo-American culture] runs a lot deeper then the rating bodies.
I know (and that's putting it mildly!). Just wanted to give an example of a reasonable ratings board, to at least prove that they exist. :-)
I've seen an example that works: The Danish film and video game rating system.
It differs from e.g. the US system in a number of ways:
* It's run by an independent government-sponsored organization, not the industry.
* For children not accompanied by an adult, the highest rating is "15 and older".
* Children ages 7 and up can see any movie if accompanied by an adult, no matter the rating.
* The board is charged only with determining if a film could be psychologically damaging to a typical child. They do not judge the "morals" and message of the film.
* The board features actual child development experts. As such, they know that cursing and nudity is not harmful to children, and if that's all the film contains, it will be rated "All audiences".
Example: "Harold & Kumar Go to White Castle".
USA (MPAA): 17+ (unless accompanied by an adult) due to "strong language, sexual content, drug use and some crude humor".
Denmark: 7+ recommended (but all ages admitted) due "strange and threatening persons, assaults, fights and accidents [...] all in a comedic context" (a context which could be lost on very young children).
To quote the ratings board:
The Media Council classifies films based on a perspective purely concerning harmfulness. The classification decision shall be made on the basis of an assessment of whether a film is considered harmful for children in that particular age group. When classifying films, we look at film effects, depictions of grievous loss, degree of realism, possibility of identification, inclusion of redemption within the course, genre and the expected media competences of the age group in question.
The Media Council’s view on child protection is that
* Children can manage a good thrill.
* Children are not likely to fall to pieces by the slightest push.
* Children are active users of media and, therefore, already in an early age, they have accumulated both media competencies and experiences.
* Media are good resources in children’s everyday life.
* It is acceptable that films frighten, though, only to a certain limit. The Media Council sets these limits.
we havnt even fixed the train crash issues yet... and how hard could that be :)
Not that hard. Automatic train operation is a solved problem; a properly installed, modern ATO system is safer than the best human driver, better at following time tables, and even has significantly lower energy consumption. In fact, many ATO mass transit lines cannot be run manually (without cutting down on the number of departures); human drivers are not able to keep up with the amount of traffic managed by the ATO.
An ATO will not stop the train if there's an unregistered person or vehicle on the tracks (or if the tracks are gone entirely, e.g. due to flooding). But then, the braking distance for a passenger train at speed is high enough that a human won't be able to stop it either.
Also, ATO systems may have a higher false-positive rate than manual systems... e.g. stopping the train because an umbrella has fallen on the tracks (to take a concrete example from the Copenhagen Metro). But that's an availability issue, not a safety issue. (And as noted, humans aren't able to keep up during normal operation, so the ATO still wins on availability overall.)
Full disclosure: I work with ATO systems.
See what happened in Paris and Denmark. People from Europe travel to Syria and Iraq to fight with ISIS, get training and AK47s, and then come back to Europe to kill the infidels.
Omar El-Hussein, the Copenhagen shooter, never went to Syria nor Iraq, never received any terrorist training, and didn't use an AK47, nor is there any evidence he ever communicated with terrorist organisations.
He did use a C7 rifle stolen from a member of the Danish national guard, but apparently had no weapons training. He did spend a couple of years in the Middle East years ago, but his radicalization appears to have happened primarily while he was incarcerated in Denmark.
Can they do it with corporate code where there are naming and style standards in abundance, and code reviews to ensure those guidelines are followed?
Presumably, yes. Style guides are 95% formatting, and if one RTFA (I know, I know), they look only at the structure of the parsed AST, not variable names, comments and whitespace. From the article:
Accuracy rates weren’t statistically different when using an off-the-shelf C++ code obfuscators. Since these tools generally work by refactoring names and removing spaces and comments, the syntactic feature set wasn’t changed so author identification at similar rates was still possible.
Since they look at code structure, they've even found identifying patterns that survive compilation and end up in the binary.
This is one of the coolest data mining results I've seen in quite a while.
How would the West feel about the release of a popular film in which the assassination of a living head of state is planned? How would your government behave toward you if YOU wrote a book / published a film / performed a play about this?
In 2006, Death of a President portrayed the assasination of George W. Bush. I don't remember hearing about it at the time, and even searching the website of Fox News doesn't turn up much controversy.
In 2008, AFR came out, in which Anders Fogh Rasmussen, the then-Prime Minister of Denmark (and later Secretary-General of NATO) was murdered (and also, incidentally, portrayed as a closeted homosexual, in line with long-standing rumours). It genereted minor controversy, was well-received by critics, and a failure at the box office. I found it forgettable (I literally don't remember any of it).
Of course, both films were small, independent films, and both can legitimately claim to use the controversial plot for a higher purpose. The Interview... not so much.
In addition to which, you replace it with something that requires more typing, and does not give any feedback. service nfs restart stopping nfsd starting nfsd etc.
systemctl restart nfs
Here you go; put this in your .bashrc:
service() { systemctl $2 $1; }
And the entire concept of *BINARY* logfiles,
Install a syslog daemon and put this in your /etc/systemd/journald.conf?
[Journal] ForwardToSyslog=yes
Or just install syslog-ng 3.6.1+, which requires no additional journald configuration?
xml configuration files [are] insanely stupid when X won't run, or isn't installed (like on a server).
Where does systemd use XML configuration files? (And what does XML and X have to do with eachother?)
And telling me that oh, it boots up *so* much faster means something *only* if I'm on a laptop.
Or a virtual machine, or a container...
The very first thing out of his mouth is a straw man.
+1
Basically, his arguments are :
* systemd haters have no clue about UNIX
* RedHat took a long time to notice my genius
* Gentoo users are old-farts that don't like beautifully written shiny new stuff
* Debian users are even older assholes
* You can use Gnome without systemd, but it won't work
* I listen to users, but they're all idiots
I take it that the irony of accusing Lennart of strawman arguments and then posting this is lost on you.
if [ ! -z "$STEAMROOT" ] then...
! -z is the same as -n; though personally, I find it more readable to elide the "-z" and "-n" test operators entirely:
if [ ! "$STEAMROOT" ]; then echo "BAD BAD BAD"; exit 1; fi
or
if [ "$STEAMROOT" ]; then rm stuff; fi
(And yes, this still works if $STEAMROOT starts with a dash.)
Sheesh. What kind of journal accepts a paper written by a baby?
Wasn't it like 10 days ago that we say the demise of SSL 3.0, the last version still alive? Yesterday we had news of Chrome dropping support for it.
Now facebook it setting up new servers that use it?
SSL 3.0 is from 1996. The latest version of SSL is called TLS 1.2 and is from 2008, with 1.3 under development.
http://www.scientificamerican....
Solar is the real eye opener and should serve as a lesson on blindly trusting hype and "What seems obvious." Solar panels are terrible for the environment,
It's always important to remember that there's no such thing as free energy. That said, the linked graph doesn't say anything about solar being "terrible for the environment", only that other sources of electricity consumes* very little silver compared to solar (as Scientific American also notes in the graph). Importantly, it does not show how that use compares to e.g. worldwide silver use.
* "consumes"? "wastes"? "produces as a byproduct"? Pretty sure that oil energy (or biomass!) doesn't consume uranium, even if drilling for oil produces it as a byproduct. Not sure what exactly is being graphed here, honestly. Unfortunately, the cited report is paywalled.
Anyway, if you look at the other report cited by Scientific American as the graph source, in figure 4 on page 19, it shows the global material requirements (in giga-grams, that is, kilotons) under various energy mix scenarios. Neither silver or tin use even registers on the graph in the so-called "non-fossil" scenario (mix of solar, wind and hydro - and no nuclear). In other words, in the "non-fossil" scenario, silver and tin usage for power is less than 1 kiloton a year. Worldwide silver use in 2013 was 34 kt.
As a bonus, silver recycles better than aluminum, with energy savings of 96% (table 4.4).
It seems whenever people want to show how simple a SysV init script can be, they pull out examples that don't do half of what the (still much shorter) SystemD unit file does.
In this example from Slackware:
- 'sendmail' is a globally reserved name for a binary; only the system-wide sendmail daemon may use it.
- you cannot query the service status.
- there's no automatic preprocesing of sendmail config files (rehashing etc.)
- there's no dependency information
And that's just what's missing compared to the Fedora SysV init script.
The Fedora SystemD unit file adds at least the following features:
- the ability to reliably stop or restart the service
- automatic restart if the service dies
1.6M? The U.S. prison population is 2,266,800 according to Wikipedia. It's been over 2M for years, and was 2,418,352 in 2008.
In the U.S., the word "prison" is more specific than you think. Look at the third figure from the top at your own link.
In 2010, the U.S. prison population was ~1,518,000 (state and federal prisons). The U.S. jail population was ~749,000. The sum of those is 2,267,000; then comes another ~90,000 in juvenile detention (see the table below the figure). Add all these (and a bunch of smaller numbers, such as holding facilities for immigrants, and military facilities), you get the number of incarcerated people, which is the number you mention.
But yes, AFAIK the U.S. still incarcerates more people than any other country in the world, both as a fraction of the population, and in absolute numbers. There's a long way down to the next on the list.
Enh, seems to be only off by a factor 10, though IANAEE (I am not an electrical engineer). Forgive me if I'm missing a factor 1.44 or something, below.
Obviously you don't charge an electric car battery at 12 V. What the individual cells do is irrelevant, since they charge in parallel; the bottle neck is the cable attached to the car (and cooling, but hey, we're assuming magic new wonder battery tech, so I'll conveniently ignore that issue).
The highest power available using standard CEE (IEC 60309) plugs and mainline voltage is 3 x 125A x 230V, or about 86 kW. This is not normal in a home, obviously, but you can easily get a couple of these in commercial installations.
Ignoring losses (I know, I know), 86 kW means one hour to fully charge a Tesla Model S with the big 85 kWh battery pack, but that's also a big battery pack.
Charging the 48 kWh battery of the upcoming Model E to 70 % will take: 70% x 48 kWh / 86 kW = 23 minutes.
Now, I would've thought 3 x 125 A x 230V was about the limit, simple due to the weight (those cables are very heavy!). But apparently, Tesla Superchargers go beyond this, to more than 120 kW (340 A x 360 V), with possible plans for 135 kW or even 150 kW. (I guess if the cable is short enough, and you increase voltage beyond mains voltage...) This gives you 70% x 48 kWh charging times in as little as 17 minutes (120 kW) or even 13 minutes (150 kW). Still a far cry from 2 minutes, but then the 17 minute figure is using current mass-market technology.
Yup, this is what you get when a short-sighted totalitarian government messes with the water cycle to enable farming in a desert, consequences be damned.
Come to think of it, California is what you get when a short-sighted democratic government messes with the water cycle to enable farming in a desert, consequences be damned.
Let's face it, environmental concerns wasn't really on any government's radar until the 70s. (And a lot of countries still try to ignore them...)
It really has nothing to do with the default shell. It won't matter what shell is the default when your CGI script starts with #!/bin/bash.
No, no, no, no... People really don't get the scope of this.
It doesn't matter what the default user shell is, or what language a CGI script is written in. Bash is the most common system shell, which means it's invoked all the time when other programs run commands.
Obviously, I can't know this, but OP is probably not using csh as his system shell, because that's not POSIX compliant and would cause major breakage.
If /bin/sh is Bash, you're vulnerable, no matter what shell you're using yourself, or what language your CGI script is written in.
Also, CGI scripts is only the most obvious attack vector; others that have been identified so far are the CUPS printing daemon, the ISC DHCP client and locked down SSH shells like those commonly used to host Git repositories. But there are without doubt many more. The only safe thing to do is to upgrade or remove Bash from your system immediately.
No, it is any CGI program that sets an environment variable to unchecked user input and then invokes a shell or calls any other program that invokes a shell.
Got that?
No, it's not the CGI program that sets the HTTP_USER_AGENT environment variable, and this is not a vulnerability in the CGI program nor the CGI protocol. The fault lies 100% with Bash, which executes arbitrary shell code from arbitrary environment variables.
any CGI program + any non-Debian Linux => vulnerable
No, only CGI programs that use system/popen/etc to call out to things that may be bash.
Enh, good luck auditing even just a resonably complex CGI program for direct and indirect invocations of the system shell.
For instance, care to guess whether this one is safe?
For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)
Well for one most languages the equivalent facility is available and usually used since it is a requirement to scale.
I know, mod_perl and mod_wsgi on Apache, and of course, Fast CGI. But CGI is still common in a lot of setups.
For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.
Even if you don't call out to the shell yourself, the standard library might.
Pop quiz 1: How is the PHP mail function implemented?
Pop quiz 2: What parts of the Python standard library module uuid are safe to use, and what parts will render your CGI script vulnerable?
I guess I was wrong to play down the severity of bash, but my hope was for people to just consider themselves to make a mistake by ever potentially having bash in a cgi context, for reasons beyond this exploit.
It's the system shell. It's everywhere. The real lesson here is to not use a big bulky program like Bash as the system shell.
Answers to pop quiz:
1. popen to execute sendmail program.
2. The following Python CGI script is vulnerable: import uuid (that's it). (uuid uses ctypes.util.find_library, which uses popen).
These examples took me less than 20 minutes of grepping to come up with, and I'm not even trying to hack any computers...
In those days [late 80s/early 90s] revision control wasn't universally used. Even as late as the early 00's I was training engineers coming out of master's degree IT programs who had no idea how to use a revision control system.
Linus didn't use a revision control system for the Linux kernel until 2002.
(Aw... comparisons between CVS and the "soon to be finished" Subversion. How quaint.)
Basically, this Bash bug is really only exploitable by remote users because of some questionable decisions made in designing the software stack.
Hm, no, the fault here lies squarely with Bash choosing to interpret an environment variable called HTTP_USER_AGENT as a program to execute.
This is not about accepting arbitrary environment variables; CGI puts data in a few, well-defined variables. This is a perfectly legimiate use of environment variables. (And Windows does the exact same thing.)
You're right that using a "full-bore shell program" such as Bash as the system shell is moronic. It is, unfortunately, still the norm on all major Linux distros except Debian and derivatives (which use the limited Dash shell, which is not vulnerable).
Primarily, I think this is a wake up call for Fedora, SUSE and the others: Bash is a huge, complex component, evidently with insufficient security review, and should not be used as the system shell. Debian dropped it for performance reasons, but now we can add security concerns to the list. It can stay around for use as an interactive shell (though why you'd do that when you have zsh, I don't know...)