I agree, and having SQL inside the source of scripting language also opens a different can of worms - the possibility that an attacker can download the scripts and understand the database model and through that craft targeted attacks.
Just realize that a null pointer dereference isn't necessarily a security issue, it's a potential security issue and it's a potential stability issue.
If the application just bombs when you encounter it and returns a server error page once in a while then it's not a big deal, but if someone can feed the pointer data through a crafted request it's a different matter.
Just use Valgrind and Splint and you will shoot most of the blatant errors. But there are still the area of not so obvious errors that are harder to catch. A common one is to have a login page that's protected but then it calls on web pages that don't check if you are logged in or not, and if not every page do such a check then you may have a solution where you have a gate into your compound but no (or a very low) fence.
The report only concerns security bugs, not all bugs. Most security issues with JavaScript are likely to have been hammered out now.
But JavaScript do fail from time to time on web pages, especially if there's a web page that do something that was permitted in an earlier version but not permitted any longer due to a security issue with that functionality. Another headache with JavaScript that most programmers today have rectified is browser differences.
Some browsers have taken in functionality from competing browsers to ensure compatibility so some issues with JavaScript have been resolved that way as well.
Java libraries - they are good, but also a curse since you can't ensure that you get everything right with the library functions in all cases. Experienced programmers may have their own library of JavaScript functions to use when they make their web stuff.
What everyone must be aware of is that the security issues that exists with Java have primarily been related to the plugin in web browsers, where attackers could gain access to the client machines through specially written applets. Server side Java has rarely been the problem, and most of the server side Java problems have been due to badly written applications not the language itself.
My personal experience is that using a language that requires compiling vastly decreases the amount of possible bugs if all errors and warnings are resolved. But when you take a language like PHP then you have two inherent faults, the first is that it's not a compiling language so you will get the errors at runtime, the second is that you get a mixed code where you get a mix of HTML and PHP. The second problem is also present in ASP, ColdFusion and JSP (Java Server Pages), which accounts for the top 4 on the Softpedia list.
However anyone coding Java and not turning on a majority of warning options in tools like Eclipse, using tools like FindBugs and using Generics is risking to produce code with unnecessary bugs and memory leaks. Use all the resources that are available to you to catch problems early, that will save you headache in the future. Same goes for other programming languages as well, like C and Splint. There are also Lint of C++, but my experience so far is that there are shortcomings there. C# also have a few tools available to help the programmer find bugs, but my experience is that they aren't as good as FindBugs.
Languages like C and C++ suffers from additional shortcomings inherent by the languages themselves like pointers that can wander outside intended memory areas, and in those cases the tools like Valgrind are great. But C and C++ are also good from the perspective that it's easy to write extremely efficient code. Even though large systems are written in C and C++ it's not something I'd really recommend for anyone starting from scratch these days. Instead use languages that don't have built-in weakness when it comes to pointers and use C or C++ for specialized functionality where it's hard to use C#, Java, Fortran, Cobol, Compiling Basic etc.
And for Python fans: It's as I see it a semi-compiling language, with the advantage that it's easy to write code in it, but with some shortcomings from classic interpreting Basic - it's hard to manage a large system written in that language.
Sometimes it's also better for management to not know everything, they may look like retards at first glance but if they were informed about every SNAFU that occurred they wouldn't be able to do their jobs.
It's also a security matter, if a manager knows everything that is to know then that person is also a security risk.
Sometimes that's why companies pays people for early retirement. There's nothing to gain from firing someone as a scapegoat officially, it's better to keep stuff out of the news.
At least officially the person is retired. And the company may still have a hook on that person in case they need something.
Unfortunately systemd is what can cause a huge security hole, not solve it. The reason is that it's so hard to penetrate fully that it's possible to misconfigure while the init scripts are easy to understand and set up if you are familiar with the usage of "su".
I have actually watched a lot of videos by bosnianbill and I'm not even remotely surprised by the outcome of this.
Cheap locks are weak, expensive locks may result in delaying the intruders enough to make it inconvenient to make entry and pick easier alternatives. If they really want to break in then they don't care about a lock anymore but take down the wall instead.
I have concluded that the weakest lock to be considered are the ABUS Granit series of locks, and that the alternatives are Abloy and Anchor.
Only the ABUS Granit series is good enough though, even if even the 37RK/80 only scores a 4 out of 5 in the SBSC security rating for locks. Also look at the Abloy and Anchor locks.
I agree, the lawsuits only makes Master Locks look stupid while serious lock manufacturers actually learns from how the locks are picked and make better locks the next generation.
Meanwhile the Abloy disc lock that's very hard to pick still is available over the counter in a model with keys almost identical to the keys that were available in 1907. They have improved versions as well today that are considered to be very hard to pick.
Even put up the layer to use disc type cylinders like Abloy have instead of pin type cylinders. Still pickable, but only with a special tool and a lot more time.
Honestly seeing the Master locks makes me wonder what they are supposed to protect - child toys?
Chernobyl and Three Mile Island were it's own making. The headache is how to take care of the problem when it goes sour and has contaminated an area for a long time.
But it shouldn't stop us from developing the beast, it just tells us to be careful and not tease it. Going fusion powered would be nice.
Depends on where in the world you are, but diesel locomotives usually have a generator that produces electricity to electric motors for traction. It allows for a smoother transition of power since the electric converters acts as a gearbox. In western Europe most trains are electric but on some tracks there's no overhead lines and then the diesel-electric locomotives are used.
A hybrid is essentially just having both overhead lines and diesel engine/generators to feed the traction engines.
However when it comes to overhead electric lines there are a large number of variants ranging from 16kV 16 2/3 Hz to 25kV DC and in between variants with 50Hz as well.
No, you are definitely wrong. Systemd is only sold into the larger distros and forced down on sysadmins all over the world. Not unlike how Windows was pushed.
Systemd != Linux and Linux != Systemd.
Systemd is very much like a prison that locks up users into a closed community. Very much like Windows.
Slashdot Mirror
I agree, and having SQL inside the source of scripting language also opens a different can of worms - the possibility that an attacker can download the scripts and understand the database model and through that craft targeted attacks.
Just realize that a null pointer dereference isn't necessarily a security issue, it's a potential security issue and it's a potential stability issue.
If the application just bombs when you encounter it and returns a server error page once in a while then it's not a big deal, but if someone can feed the pointer data through a crafted request it's a different matter.
Just use Valgrind and Splint and you will shoot most of the blatant errors. But there are still the area of not so obvious errors that are harder to catch. A common one is to have a login page that's protected but then it calls on web pages that don't check if you are logged in or not, and if not every page do such a check then you may have a solution where you have a gate into your compound but no (or a very low) fence.
A correction, none of the top three are Java.
The report only concerns security bugs, not all bugs. Most security issues with JavaScript are likely to have been hammered out now.
But JavaScript do fail from time to time on web pages, especially if there's a web page that do something that was permitted in an earlier version but not permitted any longer due to a security issue with that functionality. Another headache with JavaScript that most programmers today have rectified is browser differences.
Some browsers have taken in functionality from competing browsers to ensure compatibility so some issues with JavaScript have been resolved that way as well.
Java libraries - they are good, but also a curse since you can't ensure that you get everything right with the library functions in all cases. Experienced programmers may have their own library of JavaScript functions to use when they make their web stuff.
None of them are Java.
What everyone must be aware of is that the security issues that exists with Java have primarily been related to the plugin in web browsers, where attackers could gain access to the client machines through specially written applets. Server side Java has rarely been the problem, and most of the server side Java problems have been due to badly written applications not the language itself.
My personal experience is that using a language that requires compiling vastly decreases the amount of possible bugs if all errors and warnings are resolved. But when you take a language like PHP then you have two inherent faults, the first is that it's not a compiling language so you will get the errors at runtime, the second is that you get a mixed code where you get a mix of HTML and PHP. The second problem is also present in ASP, ColdFusion and JSP (Java Server Pages), which accounts for the top 4 on the Softpedia list.
However anyone coding Java and not turning on a majority of warning options in tools like Eclipse, using tools like FindBugs and using Generics is risking to produce code with unnecessary bugs and memory leaks. Use all the resources that are available to you to catch problems early, that will save you headache in the future. Same goes for other programming languages as well, like C and Splint. There are also Lint of C++, but my experience so far is that there are shortcomings there. C# also have a few tools available to help the programmer find bugs, but my experience is that they aren't as good as FindBugs.
Languages like C and C++ suffers from additional shortcomings inherent by the languages themselves like pointers that can wander outside intended memory areas, and in those cases the tools like Valgrind are great. But C and C++ are also good from the perspective that it's easy to write extremely efficient code. Even though large systems are written in C and C++ it's not something I'd really recommend for anyone starting from scratch these days. Instead use languages that don't have built-in weakness when it comes to pointers and use C or C++ for specialized functionality where it's hard to use C#, Java, Fortran, Cobol, Compiling Basic etc.
And for Python fans: It's as I see it a semi-compiling language, with the advantage that it's easy to write code in it, but with some shortcomings from classic interpreting Basic - it's hard to manage a large system written in that language.
Sometimes it's also better for management to not know everything, they may look like retards at first glance but if they were informed about every SNAFU that occurred they wouldn't be able to do their jobs.
It's also a security matter, if a manager knows everything that is to know then that person is also a security risk.
Sometimes that's why companies pays people for early retirement. There's nothing to gain from firing someone as a scapegoat officially, it's better to keep stuff out of the news.
At least officially the person is retired. And the company may still have a hook on that person in case they need something.
I wouldn't really call it false positives since there's a sliding scale between giant planet and star.
It would have been a lot worse if it was revealed that there was no object at all.
Unfortunately systemd is what can cause a huge security hole, not solve it. The reason is that it's so hard to penetrate fully that it's possible to misconfigure while the init scripts are easy to understand and set up if you are familiar with the usage of "su".
Even with such a tool the latest versions of those locks like the Abloy Protec2 it will take some time to pick them, and you need to get the tool.
It's a question of delaying the criminals and if it's complicated enough then they go for an easier target or go for the more violent version.
And how long is the lifetime of the key? A week before it breaks off?
The keys seems to be really bad and not holding up - they will easily snag and break off the coding part render the key useless.
I have actually watched a lot of videos by bosnianbill and I'm not even remotely surprised by the outcome of this.
Cheap locks are weak, expensive locks may result in delaying the intruders enough to make it inconvenient to make entry and pick easier alternatives. If they really want to break in then they don't care about a lock anymore but take down the wall instead.
I have concluded that the weakest lock to be considered are the ABUS Granit series of locks, and that the alternatives are Abloy and Anchor.
I want you to try the ABLOY PL362 with a $20 bolt cutter. Make a YouTube video and post the result.
Only the ABUS Granit series is good enough though, even if even the 37RK/80 only scores a 4 out of 5 in the SBSC security rating for locks. Also look at the Abloy and Anchor locks.
I agree, the lawsuits only makes Master Locks look stupid while serious lock manufacturers actually learns from how the locks are picked and make better locks the next generation.
Meanwhile the Abloy disc lock that's very hard to pick still is available over the counter in a model with keys almost identical to the keys that were available in 1907. They have improved versions as well today that are considered to be very hard to pick.
Personally I'm only considering the locks from Abloy, ABUS Granit Series or Anchor.
It's a hardware hack, and even nerds needs locks - sometimes more than others due to more expensive toys.
Even put up the layer to use disc type cylinders like Abloy have instead of pin type cylinders. Still pickable, but only with a special tool and a lot more time.
Honestly seeing the Master locks makes me wonder what they are supposed to protect - child toys?
The only good way to get what you want is to build one.
It's also a good exercise.
Word fort, almost impossible to penetrate, should be edited for readability.
A more prominent danger is the risk of terrorists invading a nuclear plant and force it to blow up Chernobyl Style - quite a dirty bomb.
Chernobyl and Three Mile Island were it's own making. The headache is how to take care of the problem when it goes sour and has contaminated an area for a long time.
But it shouldn't stop us from developing the beast, it just tells us to be careful and not tease it. Going fusion powered would be nice.
Partially right, but the waste that nuclear enrichment causes is "hot" and toxic.
Depends on where in the world you are, but diesel locomotives usually have a generator that produces electricity to electric motors for traction. It allows for a smoother transition of power since the electric converters acts as a gearbox. In western Europe most trains are electric but on some tracks there's no overhead lines and then the diesel-electric locomotives are used.
A hybrid is essentially just having both overhead lines and diesel engine/generators to feed the traction engines.
However when it comes to overhead electric lines there are a large number of variants ranging from 16kV 16 2/3 Hz to 25kV DC and in between variants with 50Hz as well.
No, you are definitely wrong. Systemd is only sold into the larger distros and forced down on sysadmins all over the world. Not unlike how Windows was pushed.
Systemd != Linux and Linux != Systemd.
Systemd is very much like a prison that locks up users into a closed community. Very much like Windows.