FOSS developer survey: Mostly male, employed... and many don't care about 'soul-withering chore' of security A new survey of FOSS (Free and Open Source Software) contributors, conducted by the Linux Foundation and academic researchers, reported that 91 per cent of respondents are male, the great majority has full-time paid employment, and that they spend on average under 3 per cent of their time on security issues, with little …
In addition to automated tools.
Should also include someone who is not the author - ideally an expert in security flaws.
Lot's of developers will not even be aware of the potential security issues with some of the code they produce (far too little proper training / education & too much learning on the job / in your spare time)
That would require that security experts join FOSS projects.
The survey suggested that half the people working on such projects are actually paid to do so. The employers sponsoring them might usefully consider seconding any such specialists they have on their staff to spend some time doing this. However some such companies may only be contributing to the extent that specific features of the project benefit them and may be reluctant to pay for something that benefits the project as a whole - including other contributors who may be commercial rivals.
Other projects which can be quite critical to the whole FOSS "ecosystem" have turned out to have very few contributors and generally run on something less than a show-string with no commercial support. That needs some external foundation to step up to support them.
What is to be done? The report noted that bearing in mind their motivations, “it is unlikely that simply offering money to contributors for focusing on security will move the needle a great deal.”
Perhaps people who aren’t in the majority in this survey (e.g. people in Africa; women; men under 25 or over 44; people without full-time paid employment — some of these categories could overlap) have different motivations, and offering them money might help to move that needle.
I agree regarding security, but can it be presumed that the 25–44 male majority of the FOSS-contributing respondents in this survey are old hands at security? If full-time paid employment in security can motivate some people, then putting money into training newbies from that motivated cohort might not be a bad investment.
Yes: we all hate it, but without it other will find it hard to use what you write. Others cannot see the inside of your head and grasp what, to you, is completely obvious. This is also a security issue: others might get your creation to work, but not having understood some undocumented subtlety leave some door wide open.
This is not just a problem of FLOSS code.
Some do have excellent documentation, eg jQuery
There is API-level documentation, of which most projects I encounter are quite good or even excellent, and there is explaining what is going on inside the code. I assume that we're discussing the latter.
The problem is that documentation is a second source of truth, and, as I first heard in the nineties, "documentation is always out of date". In general, if your code needs explanation, the real solution is to simplify it (and/or name variables carefully).
And that is hard.
Yes.
I'll add that there are _*2*_ [categories of] end-users typically ignored.
1. the end-user of the software's run-time.
2. the end-user of the software's code AKA the developer-after-you.
Most doco is just a reference manual.
An actual Dev's "userguide" for the physical code lets the Dev start faster and harder and deliver much better code in terms of architectural coherence.
Sadly, it's the category which almost never is written.
If you're talking about the python website, I suggest you check the ruby website & report back.
I consider the python website to be the first demonstration that the term "Pythonista" is well-earned. Not that I've interacted enough with the python community to render judgement, but I found that website to be atrocious. (I found three different pages which, together, appear to explain what you can do with a list. With no way to effectively search the term.)
The general public don't give a dingo's kidney for security - that's why faecesbook and google etc are so profitable, and why Amazon manages to sell internet-based home "security" kit.
Why would the average software bod care? They should - yes. But in reality, no. I used to run a commercial website based on an open source framework osCommerce. I found out very quickly that most of the people developing with it didn't give a shit about security, either of their web site or (most depressingly) their customers. The problem is not limited to e-commerce of course.
One problem is that good security is difficult and most people don't know where to start with it, and have little inclination to find out. And if Bill Bloggs develops a program to twiddle some stuff about, as long as it works for him then he's likely happy; it's not his problem if someone picks up his program and gets borked as a result. I think it's more a reflection of the sad state of humanity than poor engineering practice (which it is, of course)
I'd go a step further. The average member of the pulic doesn't want security because it would make the product more difficult to use. Security generally gets traded off for something - convenience, performance, cost, whatever. Right up to the time it becomes obvious it shouldn't have been.
Yup. Elsewhere, away from Foss.
(not me, I'm not a developer, I write code, yes, as an end to means, but I would not call myself a developer. I was involved in FOSS a while ago, working on a community translation project for documentation)
"Well maybe a prison sentence would help you focus your attention a bit ?"
Erm? You want to throw people in jail for giving away bad code? Does it have to be the person who wrote those lines, or just anyone who contributed? If Linux has a flaw, does Linus get hauled off in the back of a cop car?
Around 1980, Matel released a version of Barbie which would "speak" when a string was pulled. On of the phrases that could be played was "math is hard". This caused the now-familiar uproar, and as a male mathematician, pushed me over the edge towards boycotting Barbie for my own daughters.
But that does not mean that the phrase itself is not absolutely true. Mathematics is hard. Most of the people majoring in mathematics will never enter graduate school, and the majority who do will not pass their prelims. This is not, as a rule, because those students are any lazier than those who succeed. I call myself "brain-damaged in a socially useful fashion" because of just how different I appear to be wired than the rest of the world. For me, mathematics really was pretty easy for everything up to that point except for one of my prelim courses. (Don't hate me--I suck at sports.)
If you cannot pass your prelims, then, at some important level, you won't be successful producing mathematical proofs.
And how can you know that the code you just wrote is secure if you cannot produce a mathematical proof that it is secure?
It's not quite that hopeless. I expect that there are engineering practices which can be put in place that will allow secure code to be produced. Those practices must be developed by mathematicians (they will be called "computer scientists"), and strictly enforced to work, however.
"Expect." Honestly, I know of a bunch of things to avoid, but I fall back to doing proofs whenever it matters. Because I can.
And how can you know that the code you just wrote is secure if you cannot produce a mathematical proof that it is secure?It's not quite that hopeless. I expect that there are engineering practices which can be put in place that will allow secure code to be produced. Those practices must be developed by mathematicians (they will be called "computer scientists"), and strictly enforced to work, however.
I will just address a dangerous and incorrect inference that many will make from your statement: "the code you just wrote is secure if [you can] produce a mathematical proof that it is secure".
For many will assume that mathematically rigorous code is secure.
Mathematical correctness is a necessary condition, but not sufficient.
1) From a mathematical point of view, proven code is demonstrated to follow rigorously from a set of assumptions. The first challenge is making sure that all your assumptions are valid and apply to the 'real' world. This page on the formally proven seL4 microkernel goes into more depth: seL4 - What we prove...what we assume. There is a telling quotation there: "Mathematical proof is proof as long as it talks about formal concepts. It is when assumptions connect to reality where things may still fail. Albert Einstein is quoted as saying 'As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality.'", which leads on to...
2) While the algorithm may be demonstrated to be secure under the chosen set of assumptions, it is implemented on real world hardware, which is subject to side-channel attack, e.g. timing attacks, power-fuzzing and a panoply of other techniques. AES is a pretty well proven encryption algorithm but difficult to implement in a secure manner in silico ( Cache Based Remote Timing Attack on the AES ). There are decades of work, some of which is either not classified, or now unclassified dealing with working with EAL/Common Criteria and equivalent security requirements and the hardware issues that have to be resolved.
3) The hardware your code is implemented on can be compromised in subtle ways, even at the gate level (Stealthy dopant-level hardware Trojans: Extended version : April 2014Journal of Cryptographic Engineering 4(1):19-31 : DOI: 10.1007/s13389-013-0068-0 ). Bullet-proof code can be compromised by tissue-paper hardware. If you cannot trust the hardware your code is running on, it makes it difficult to claim your system is secure, even if the code itself is formally proven.
There are indeed engineering practices that can mitigate many of the known security vulnerabilities. TEMPEST is one such set of practices which may or may not be over the top for most people.
A formally proven piece of code is only one step on the long path to secure information processing.
NN
Addendum
1a) One person's experience of use of formal verification is here.
Ray Wang: Formal Verification: The Gap Between Perfect Code and Reality
tl;dr Formal Verification is hard, and there are plenty of examples of it going wrong.
That said, from my point of view, formal verification is obviously useful, and is used in many areas (including chip design and cryptocurrency), but has not made inroads into general-purpose computing as yet. And formal verification is only part of the story: it is all well and good showing that the program correctly implements the specification; but humans write the specification, and there is a great deal of room for specifications to be incomplete and/or inaccurate.
It hasn't made it into general purpose computing, and most likely never will, for one very simple reason: Diminishing returns.
For the most part, we muddle through and the stuff that needs to be secure is pretty much as secure as it needs to be. When we find holes, we plug them. Lather, rinse, repeat.
Before you poo-poo the above, kindly consider the patchwork of band-aids on top of band-aids that makes up the inherently unsecure and unsecurable Internet itself.
I was addressing the one part of the problem which programmers can address--their own code.
The hard part of applying proofs to the real world is uncovering the assumptions that are being made. That is the critical aspect of a mathematician's training, and the difference between what one will accept as a theorem and what will scooch past someone else. Your comment does a nice job of uncovering what is needed for a complete claim of correctness.
However, I specifically did not bring in formal checking. Formal tools are always going to lag in capabilities, and, in the hands of people who are not mathematicians, are readily abused.
Quote:
"And how can you know that the code you just wrote is secure if you cannot produce a mathematical proof that it is secure?"
One of the things my lecturer in distributed computing explained to us is that if you are using a real time system with interupts generated by external events(timers/comms/keyboard presses) , then it is mathematically impossible to prove the system.
The only way to do a proof would be to enforce a single threaded system that relies on internal timers and offers an output when it wants to rather than when the user wants it to. of course systems like that exist, used in very specific situations (usually monitering systems). but would be a pita to use for something like this PC i'm sitting in front of (or a coffee dispensing machine)
The only thing you can do is to use engineering best practise to try and avoid falling into the obvious security traps (buffer overrun anyone?) but you are still at the mercy of whatever system your application is running on.... eg password needed... tap tap tap enter passy while a keylogger is records everything you do......
That depends entirely on what you are trying to prove about it, and what the nature of the system is.
Given that the definition of a realtime system is that a response will be placed on a bus within X cycles of an interrupt Y being received, I expect he was overstating things.
However, unless you have an infinite memory which can be addressed in constant time, interrupts WILL be dropped on the floor. I expect what he showed was some variant on this.
You can prove that supervisor state won't corrupt, or that a stack won't overflow--or even that a system design is in fact realtime. But it will have a limit on how many interrupts per second it can handle.
Barbie didn't say "Math is hard". Barbie said "Math class is tough". There is a big difference between the two statements ... the idiots bitching about it made it sound like they were equivalent, though, so history has substituted the shorter of the two into the collective psyche.
I agree with those who suggest we need to address the culture of rewards to increase the focus on security.
Start with the CS programs, certainly. No, we need to start earlier than that.
I taught engineering calculus. My students hated me because I gave 0 points if they made a sign error. I pointed out that if they made a sign error on gravity, that their bridges would not be trustworthy. They did not buy it. I asked them how they would feel if their bank made a sign error in their paycheck? They shut up only because they could see that I would not budge.
My accountant made a sign error this year that would have cost me $6000.
"Sloppy" mistakes cannot be tolerated in programming, and thus, in our mathematical coursework. But students are conditioned to expect that such errors are acceptable.
And I'd be quite annoyed too, because you're teaching them bad practice. You think trying to teach your students to never make mistakes is going to stop them making mistakes? Because that's never going to happen. You show me someone who never makes mistakes and you'll be showing me a liar.
In real world engineering we accept that mistakes will happen, so we design systems to mitigate and catch those mistakes before they become problems, and have further processes in place to correct problems once found. Say in my field, any engineering drawing will have two different checkers, we'll have design reviews, we'll have prototypes. And after all that when the product is actually made we'll have several rounds of verification testing as well.
Good software is similar. While obviously you try and get it right first time, you won't. So you write unit tests, you have peer code review, you have offline testing etc. And then at the end you should also have a QA/QC process to check it's all working. Obviously this is all boring stuff but if you want good product this is whats needed, not just relying on your developers/contributors to never make mistakes.
I think you are mis-representing the OP and, in fact, the OP is trying to encourage students to do (in maths) what you are advocating (in software). To wit...
So, you've arrived at an answer? Well done! Come back when you've figured out a way to check it.
I did not say they would fail the class or a test if they made an error. I said that they would get 0 on that problem. The goal is to get the student to be certain that they are following the rules that they were given exactly in order to arrive at their answers.
These days, I would be tempted to take a bright second-grader and have THEM check the work. There is absolutely no problem in engineering calculus whose correctness requires anything more than attention to detail to check. (That wasn't true 50 years ago, by the way. The dumbing down of calculus tests has been atrocious.)
Software is MUCH harder to get right. If you turn in calculus homework with errors in it, you should not be allowed to program.
Slightly OT but related, and a Fun Fact :
Sign Errors are rife in finance due to its nature. And every financial engineer/structured/complex trader has always to double and triple check their signs all the way through as soon as they step away from vanilla exotics or routine structures.
The consequences are not just obviously large but $$impactful.
Amusing low-cost example just in utter vanillas. The custom keyboard for FX Traders (super high volume, super low transaction costs) has custom Buy & Sell keys. In a head-exploding UI failure, these are right next to each other, jammed together.
It is not uncommon when the market is running hot, for FX Traders watching the trades&prices zooming past to have a bit of a laugh as they see, for example, all to/from one pair of counterparties : BUY usd 50m SELL usd 50m SELL usd 50m.
They all know what some poor bastard's just done. A sign error. Hit the wrong key, shouted "sh*t!!", hit the correct key twice (to return to 0, then to execute the correct sign). Tap, sh*t!, taptap.
Hey OP/Claptrap31pi, good example for your PhD-level students:
Dig up Li's classic piece on Copula Correlation. (Top hit on Google/ddg for those 3 words; the original RiskMetrics PDF is the most readable.)
A/ AWESOME maths. Just... beautiful.
B/ catastrophically broken by dint of a single error.
Due to the maths' extraordinary parsimony for numerical application to summarising bundles of probability distributions (eg, pricing baskets of credit default risk), and allowing whole trades to be expressed, and hence managed, as a single number, the financial markets leapt on it en masse. I accidentally made almost an enemy of my best and favourite physics PhD when he brought it in really excited and I read it and laughed at it and said it was magnificent but broken.
8yrs later it all went bang (the core driver was politicians forcing retail banks to explode mortgage lending for highrisk/broke people, but if not for this maths technique fooling the wholesale boys downstream, Lehman's et al would have been backpedaling hard much much earlier and the fallout would have been "merely" major rather than catastrophic) and a year or two later someone publicly twigged the maths error.
"Whoops"
Great example for your students.
It's not really all that bad. Documentation takes forever, because it is a constantly changing target. If you don't believe me, try writing it for any ongoing software project, be it FOSS or otherwise.
Security, however, should be part of the code framework right from the git-go, and as such probably shouldn't take all that much of Joe Average Coder's time ... assuming, of course, that JAC is competent in the language of choice for the project, which is a whole 'nuther kettle o'worms.
If only. What I was trying to say politely is that JAC lacks the capacity to produce valid proofs. He therefore cannot be expected to do an adequate security review of anyone's code, let alone his own.
Tooling can deal with classes of errors. Methodology can deal with more classes of errors. Careful discipline can ensure that methodologies are adhered to. But the unknown unknowns remain.
Who knew so many coders were Hipsters then
Ooooh shiny
Ooooh new fucktionality
Old code, BORING!!!
At some stage in your life, you have to evaluate what you’ve created and take a moment to see if it is actually working. Stop piling shit upon shit
I honestly dont think a distinction between FOSS and propriety needs to be made here, they’re all equally hipster’ish when it comes to coding, focusing more on new fucktionality rather than perfecting the existing fucktionality
Security is difficult but the main issues are related to people's mindset. Examples:
1. I discover a WordPress bug. PM punts the already tested dot security only update to after Black Friday. Site gets hacked. Client spends a month digging themselves out of the hole. Cost? Don't ask. We made a lot of money billing them.
Moral of the story? PM fires the implementation team.
2. Client believes that encryption of firmware is good enough. Digital signing is only for others. Appealed to the executives to get our contract terminated. One year later Codecov happened. Now they are scrambling to cover up their loss of IP. And yes, they stuck the symmetric keys in source code as no one will be able to figure it out.
Moral of the story? Managers don't care that they tried to burn the security people. We are expendible.
3. Vulnerable jQuery. Refused to update since we had not shown them all the ways they could be exploited. I told them that weaponization would take 2 months. Updating with just require testing. Fortunately, the execs stepped in.
Moral of the story? I should have them for the 2 months to write the exploit.
4. Password stuck inside JavaScript. Admin password, that is. Checks if user is admin. If true, uses admin as password. Refused to fix the issue as no one would be able to figure it out. They did.
Moral of the story? Should have gotten that ass fired. Which they did a year later. He now works for PayPal in their senior mgt.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
