flatbield

NoScript browser extension is one example. DNS filtering is another.

In college, one of the best courses I took was Programming Languages. It covered a smattering of languages illustrating different approaches and methods. Maybe a week or so on each plus you had to write some code in each.

Android is Linux using SELinux for user confinement plus users do not have root access and it uses verified boot to enforce all that.

Keep in mind the system meaning root can do anything it wants. User apps cannot though they can ask the system to do certain things for example by SUID executables for example or other methods. Not sure how android actually does it.

What is different about Android is owner, user, work profiles, and the new private space structure. Not sure low level how that is done but presumably combination of different users, SELinix, and different encryption keys.

I think they said Pandoc. I have used that too some.

Bluefish.

Keep in mind that you actually do have control over what you and your reports use for software and their license compliance. Otherwise not your problem. Beyond that, it is an issue for legal anyway and management.

deleted by creator

Sorry, the most important thing about a language is readability and maintainability. Also speed writing bug free secure code is next. Speed of execution and sometimes memory use is next.

The order may vary depending on project.

By the way, I would not consider logging in via ssh and running a bash script to be insecure in general.

However taking uncontrolled data from outside of that session and injecting it could well be insecure as the data is probably crossing an important security boundary.

I was more thinking of the CGI script vunerability that showed up a few years ago. In that case data came from the web into the shell environment uncontrolled. So uncontrolled data processing where the input data crosses security boundaries is an issue kind of like a lot of the SQL injection attacks.

Another issue with the shell is that all proccesses on the system typically see all command line arguments. This includes any commands the shell script runs. So never specify things like keys or PII etc as command line arguments.

Then there is the general robustness issue. Shell scripts easy to write to run in a known environment and known inputs. Difficult to make general. So for fixed environment and known and controlled inputs that do not cross security boundaries probaby fine. Not that, probablay a big issue.

By the way, I love bash and shell scripts.

Bash is especially suseptable. Bash was intended to be used only in a secure environment including all the inputs and data that is processed and including all the proccess on the system containing the bash process in question for that matter. Bash and the shell have a large attack surface. This is not true for most other languages. It is also why SUID programs for example should never call the shell. Too many escape options.

Just make certain the robustness issues of bash do not have security implications. Variable, shell, and path evalutions can have security issues depending on the situation.

Now I have heard everything. What is zero? Missing value?

For what it is worth. I learned C in 1990. Switched largely to Python in 1998.

Does C have a logical type these days? Never use to.

Probably readability. Correct typing maybe too. Also better error checking.