Open Source Developers Say Securing Their Code Is 'Insufferably Boring' and 'Soul-Withering' (techrepublic.com) 150
"A new survey of the free and open-source software (FOSS) community conducted by the Linux Foundation suggests that contributors spend less than 3% of their time on security issues and have little desire to increase this," reports TechRepublic:
Moreover, responses indicated that many respondents had little interest in increasing time and effort on security. One respondent commented that they "find the enterprise of security a soul-withering chore and a subject best left for the lawyers and process freaks," while another said: "I find security an insufferably boring procedural hindrance."
The researchers concluded that a new approach to the security and auditing of FOSS would be needed to improve security practices, while limiting the burden on contributors. Some of the most requested tools from contributors were bug and security fixes, free security audits, and simplified ways to add security-related tools to their continuous integration (CI) pipelines.
"There is a clear need to dedicate more effort to the security of FOSS, but the burden should not fall solely on contributors," read the report. "Developers generally do not want to become security auditors; they want to receive the results of audits..."
The researchers continued: "One way to improve a rewrite's security is to switch from memory-unsafe languages (such as C or C++ ) into memory-safe languages (such as nearly all other languages)," researchers said. "This would eliminate entire classes of vulnerabilities such as buffer overflows and double-frees."
Also interesting: money "scored very low in developers' motivations for contributing to open-source projects, as did a desire for recognition amongst peers," according to TechRepublic.
"Instead, developers said they were purely interested in finding features, fixes and solutions to the open-source projects they were working on. Other top motivations included were enjoyment and a desire to contribute back to the FOSS projects that they used."
The researchers concluded that a new approach to the security and auditing of FOSS would be needed to improve security practices, while limiting the burden on contributors. Some of the most requested tools from contributors were bug and security fixes, free security audits, and simplified ways to add security-related tools to their continuous integration (CI) pipelines.
"There is a clear need to dedicate more effort to the security of FOSS, but the burden should not fall solely on contributors," read the report. "Developers generally do not want to become security auditors; they want to receive the results of audits..."
The researchers continued: "One way to improve a rewrite's security is to switch from memory-unsafe languages (such as C or C++ ) into memory-safe languages (such as nearly all other languages)," researchers said. "This would eliminate entire classes of vulnerabilities such as buffer overflows and double-frees."
Also interesting: money "scored very low in developers' motivations for contributing to open-source projects, as did a desire for recognition amongst peers," according to TechRepublic.
"Instead, developers said they were purely interested in finding features, fixes and solutions to the open-source projects they were working on. Other top motivations included were enjoyment and a desire to contribute back to the FOSS projects that they used."
This is expected (Score:5, Interesting)
As most people who contribute to such projects are doing it for personal enjoyment and security issues are not fun for most people.
I have maintained/been part of maintaining different codebases both as hobby and as job.
When doing it as a job I had to take security into account, but when as hobby, specially when just one of the people doing things I could concentrate on things I found interesting there and while I tried to take security into account in planning, I definitely did not go out specifically go looking for security problems. Though I did occasionally fix such when I stumbled upon such when chasing some interesting bugs..
Re: (Score:2)
I will almost say its like fanfiction. You want to write yours and don't want to be the editor of somone else's.
Re: This is expected (Score:5, Insightful)
Having spent much of my career trying to get people to secure proprietary software, I can't imagine why you think proprietary software "solves this problem".
Proprietary software dumps the money into salable features, not better security. Nobody who's not a security specialist does any more about security than they have to, not in proprietary any more than in open source. And these days, they often get those salable features by throwing a thin shell around some open source anyhow. If you're very lucky, they may contribute some fixes back to that open source. Usually not security fixes, though.
This in spades (Score:3, Insightful)
> Having spent much of my career trying to get people to secure proprietary software, I can't imagine why you think proprietary software "solves this problem".
> Proprietary software dumps the money into salable features, not better security.
Quite. Trying to get developers of proprietary software to pay attention at all to security is my job. The idea that proprietary software has "solved" the security problem is laughable. Every month, each and every month, we have dozens of security problems to patc
Re: (Score:2)
BarbaraHudson's comment is moderated "insightful"; it should be moderated "laughably ridiculous".
Nope. She was right. And if you had not a reading comprehension problem, you would agree with her post.
To solve security problems you need two things:
* people who are aware about it and can solve it
* (and that was her point) money to pay such people
If you disagree, you are not very smart.
Re: (Score:2)
I've personally bee paid well over a million dollars to solve security problems, in both proprietary ad open source software.
You think that has solved the problem, proprietary software is secure. You can think that if you want, I'm just telling you, as the guy who is paid to solve the problems, my to-do list is huge and getting bigger every day. It's very much not solved. You can think I'm lying about my to-do list, but I know what's on it.
Again I point you to the 50-100 new vulnerabilities each and every
Re:This in spades (Score:5, Interesting)
Btw, my experience over the last 20 of *actually* addressing security issues in real software, not guessing about the topic while knowing nothing, is this:
Contributors to widely used open source software know that their code will be seen by many people. It'll need to pass intentional review by 2-4 people. Programmers tend to have a little bit of an ego and don't want to be embarrassed by submitting crap. You've undoubtedly read about how Linus responds to people submitting crap. People don't enjoy someone pointing out that there work is crap. So they try really hard to not submit crappy work.
On the other hand, when the boss at a proprietary company says the feature needs to be done by the end of the month, programmers have every reason to just get it done by the end of the month. Nobody outside of their team is going to see the code (that's pretty much the definition of proprietary). Since nobody is going to see the code, only see whether the feature seems to work, the programmer cares about if the feature is released on time, not whether the code is elegant or well-executed.
That's my actual experience from doing this work for twenty years. If you want to sit a thousand miles away from the work and make random ass guesses about what's going on, go ahead. It doesn't bother me; I'll just be sitting here laughing at your clueless arrogance, that you truly believe that whatever thought comes out of your butt overrides actual reality.
Re: (Score:2)
Re: (Score:2)
Every month, each and every month, we have dozens of security problems to patch in Windows. December was a light one - only 58 new security holes from Microsoft this month.
So you're saying proprietary software pays attention to security issues and tries to patch them. Glad you clarified that. Now open source developers should do the same.
Re: (Score:2)
Proprietary software dumps the money into salable features, not better security.
Well, that kind of depends on what market you're serving. Security is a salable feature, but only to a certain customer.
The Linux community is almost entirely focused on the enterprise market, since that's where the money is in open source. No kidding security tends to be decent. Ordinary people don't fund that stuff, which is why Linux on the desktop is still a bad joke.
Re: (Score:2)
In the industry, there's no such meme as, "Your code sucks because it's insecure"
Instead, you're lauded because "It works! It screams".
Few start from the basis of a secure construct, The reasons are many, including Loose and Fast. But the parsers that compile will compile horrific code just as quickly as the good stuff, and getting through the compiler seems to be the first step, and/or "leave as little collateral damage as possible".
Oh? Doesn't work with ($unusual API, older version, $diff_OS) or an unneed
Re: (Score:2)
Axiomatically untrue. They do both.
Cite.
Re: (Score:3)
Funny how proprietary software solves this problem with money to pay devs, but open source can't.
Funny how we keep finding the same kinds of holes in proprietary software, where you think this problem is solved.
Wait, that's not thinking. It's imagination.
This is acronyms. (Score:2)
Make Security Cool Again.
Re: (Score:2)
The way to fix this is with money.
Whose money?
Funny how proprietary software solves this problem
Proprietary software has even more security holes than FOSS.
Re: (Score:3)
Re: (Score:2)
This is human nature. (Score:3)
Sounds like an inherent problem with the whole idea of "free". Freedom to do whatever one wants, means some problems will get more attention than others. Something to consider the next time one talks about the inherent betterness of open-source when no one wants to do the work to making it better.
Re: (Score:2)
> Freedom to do whatever one wants, means some problems will get more attention than others.
Yep, freedom means I will work on things that help me or someone who matters to me. It means that problems which bug a lot of people will be worked on by a lot of people. A feature that only one person wants, only one person will work on.
> Sounds like an inherent problem with the whole idea of "free".
How is doing good for more people a problem? I guess that's a problem if you happen to be a wannabe dictator
Re: (Score:2)
Re: This is expected (Score:2)
Re: (Score:2)
FYI here's the first paragraph of the report we're discussing, summarizing the responses of thousands of developers:
---
1. The top three motivations for contributors are non-
monetary.
Non-monetary motivationsââ"âspecifically adding a needed feature or fix, enjoying learning, and fulfilling a
need for creative/enjoyable workââ"âwere most frequently ranked in respondentsâ(TM) top three motivations for
contributing. Conversely, being paid to develop FOSS was the most likely motiv
Re: (Score:3)
Yeah, but the problem is that people tend to take your "hobby" code and use it for their jobs. Which is their fault, not yours, but still causes bad problems.
This is empty advantages. (Score:2)
It's their "fault" for listening to the FOSS community about the inherent advantages of "hobby code". They'll do better next time and stick with what they know.
Re:This is expected (Score:5, Insightful)
> The researchers continued: "One way to improve a rewrite's security is to switch from memory-unsafe languages (such as C or C++ ) into memory-safe languages (such as nearly all other languages)," researchers said. "This would eliminate entire classes of vulnerabilities such as buffer overflows and double-frees."
I wish this kind of stuff wasn't brought up in these discussions because it just weakens the argument that there is anything wrong with the language and rather the problem is developer incompetence/laziness.
Yes, using Rust might make the code more secure, but you know what would make the code more secure without the overhead? Linting the code, making all warnings errors, rather than ignoring them (which is a problem in nearly all FOSS projects, even ones that are critical to current operating systems.) Missing casts? Uninitialized variables, memory overwrites, access violations, yep all stuff still seen. Rust will not fix these, Rust is the equivalent of using the -Werror flag in GCC. Perhaps the problem that really needs to be fixed, is the compilers, which would require hearding more cats. GCC, Clang, MSVC, Intel, nVidia, never mind all the embedded stuff. Perhaps that should be the goal of C2x and C++23. Many projects are written to use C89 because it's the least frustrating version of the language to write in.
Rust doesn't improve anything over C that justifies switching to Rust. If anything if someone is telling developers to develop in Rust instead of C, they don't understand why the program was in C in the first place. C is for speed and efficiency, that's why all these bounds checks don't exist. All these additional check-for-stupid-programmer checks are things that already exist in C, and memory-safety errors are some of the easiest to fix without throwing out 10 years of code switching to an unproven programming language.
If you're writing something new, in Rust, and it's not performance oriented (eg Office applications) go right ahead. But if you're developing game engines, drivers, or safety-systems, that better be in C. Game scripting, GUI nonsense, doesn't need to be in C, it can be in whatever library you want, but generally anything that interfaces with the GPU is going to have to be in C anyway, and it will never run Rust. So this contined advocation to switch to "yet-another-not-invented-here-language" just harms adoption of it. Web browsers should be written in Rust, not things like openSSL.
Re:This is expected (Score:5, Insightful)
While you are definitely right that people could go a long way by not ignoring compiler warnings and by running static analysis, a language like Rust can detect errors that C cannot detect, because the code just plain doesn't contain the information. And even for errors that can in principal be detected, it's a lot faster and easier
Furthermore C is not intrinsically faster than any other compiled language with not-too-dynamic memory management. That's a question of the compiler.
And OpenSSL should be written in something tighter than Rust. If you absolutely must have a few hundred lines of performance code, then write them in whatever you need to write them in... which probably means assembly or even microcode, not C. But most of something like OpenSSL is nowhere near the performance path for either the crypto or the overall application. In fact, an office application probably has more performance-critical inner loops in it than your average crypto library.
Now, GPUs... well, you're never going to get any decent security with anything resembling a contemporary GPU anywhere remotely near the attack surface, so the first step there is to stop doing psychotic things like exposing OpenGL to JavaScript downloaded from the Web...
Re: (Score:3)
It is proven that these language features do not reduce application bugs, though.
It is just process masturbation.
In the end, the programmer has to do whatever the hard parts are the right way, without cutting corners, or there are lots of bugs. Always true.
Re: (Score:2)
but but but if you program in $NEWTHING, your code will be perfect and smell like unicorn farts!
Re: (Score:2)
> Furthermore C is not intrinsically faster than any other compiled language with not-too-dynamic memory management. That's a question of the compiler.
First, A *is* intrinsically faster than B for:
A. Read the memory location at var[x]
B1. Read the maximum index of var
B2. Compare the max index to x
B3. If x = max jump to B5
B4. If x max index
B5. Read the memory location at var[x]
The safety checks DO take time. The bounds check takes roughly 4X as many instructions as just reading the value with the bounds c
Ps that's just one of several checks (Score:2)
Ps note those four instructions are for just that one check - that doesn't mean the access is safe. The index may still be bad, for example. Just because it's less than the max doesn't make it safe. What if it's -8? We still have more checks to do if we want a "safe" language, a language that defends against programmer error. We could easily have 12-24 instructions of safety checks before we can execute the one mov instruction that actually moves the program forward.
Re: (Score:2)
Re: (Score:3)
Deal with things as they are, not as you think they should be. I say this as a professional c++ programmer in a domain that values speed and efficiency above almost all else, but this can't continue for ever. Assembler is even faster and more efficient, and we don't program in that. At some point, the water level rises to the point where the benefits outweigh the penalties. Memory unsafe language like C and C++ are really not that far off. Maybe a three or four decades, I'd imagine, given how other dead lan
Re: (Score:2)
Assembler is even faster and more efficient, and we don't program in that.
I do when I really need speed.
Re: (Score:2)
The idea that writing in assembler results in faster code than compilers is a fallacy. The compilers are generally better at writing in assembler than you are, and know more tricks regarding moving data to word boundaries and stuff like that.
Re: (Score:2)
The compilers are generally better at writing in assembler than you are, and know more tricks regarding moving data to word boundaries and stuff like that.
This is a lie. They may be better at writing assembler than you are, but they are not better at writing assembler than I am.
The trick is to use a profiler. Start by taking the compiler output, and time it. Then write your own code. If it's faster, keep it. If it's not, then change it until you end up with something faster.
Re: This is expected (Score:2)
Re: (Score:2)
Not without a lot of work. The modern C compiler produces extremely efficient code nowadays that it takes an extremely talented assembly programmer to produce code equivalent to what an optimizing compiler can emit. One has to be extremely familiar with the architecture in order to produce better code.
It's at the point where assembly use is limited to small snippets required to set up the execution environment or special architecture i
Re: (Score:3)
A decent custom string library and "memory chunk" library will fix those buffer overflows and double-frees without switching languages.
Then you're still going to have all the logic bugs...doesn't matter what language you're using if you let people log into any account with a blank password (a surprisingly common programming error).
Re: (Score:2)
Modern computers are so fast that it makes sense to trade a small amount of overhead for security.
In fact that's by far the best option. Trying to make your application perfectly secure is always going to end in failure for anything non-trivial. Defence in depth is the key, sandbox everything and limit by default.
Android and iOS use that model and the overhead doesn't cripple them, even on fairly low end devices.
Re: (Score:2)
Except it significantly reduces the amount of memory-related issues and makes concurrent programming safe, without sacrificing performance. And no, it's not about bounds checking.
> Uninitialized variables, memory overwrites, access violations, yep all stuff still seen. Rust will not fix these
It will, and it's not about -Werror flag. There is no C/C++ compiler which will prevent a double free situation or a data race in co
Re: (Score:2)
> Rust doesn't improve anything over C that justifies switching to Rust
Except it significantly reduces the amount of memory-related issues and makes concurrent programming safe, without sacrificing performance. And no, it's not about bounds checking.
I agree, but:
> Uninitialized variables, memory overwrites, access violations, yep all stuff still seen. Rust will not fix these
It will, and it's not about -Werror flag. There is no C/C++ compiler which will prevent a double free situation or a data race in concurrent code or even show a warning about it.
This is not quite true:
https://godbolt.org/z/YTYnv6 [godbolt.org]
And other tools will help to find data races.
I agree that Rust is better in this regard, but C and tools will also get better at this.
Re: (Score:2)
Rust tracks reference ownership via lifetimes and prevents this at compile time.
Re: (Score:2)
I know and yes, this is cool.
Your initial statement was just not correct because it was too strong.
My point is that C compilers also get better (and other tools can be used like valgrind) and also the language evolves.
Re: (Score:2)
Stop calling "new" and "free". Done.
Re:This is expected (Score:5, Interesting)
Rust brings some good ideas into practice. But it is a relatively young language and the tool chain still needs to mature. Also support is not nearly is wide as for C, so, no, it is currently not a replacement. Of course, also not everything rewrites itself in automatically in Rust and rewriting may also introduce new errors (and Rust protects only against certain classes of errors, in no way would a Rust program automatically be bug free).
I agree that you can write safe code in C when following some guidelines and use the the many tools available to you. Compilers are improving too and can check for much more problems than in the past.
I do not see why C89 would be more pleasant to write in than C17. I think it is C17 is a much better language than C89 and C23 will be even better. I also like to mention that C has a bounded pointer type since C99:
void foo(int n, char (*a)[n]) // will give you a run-time error on some compilers with -fsanitize=undefined
{
(*a)[n] = 1;
}
And finally, there is a quite a few people in the standard committee that would like to see C evolve into a language which can be used safely. If you have good ideas or want to see features integrated from other language, let us know! The main constraint is that it has to be remain backward compatible, but there is a lot which could be done.
Re: (Score:2)
Are there any plans to re-work printf and other functions that use format strings specifying the types of arguments? They're a maintenance nightmare. Change the type of an argument, and if the format string isn't updated to match the type, then you have undefined behavior.
They should introduce a whole new family of functions that don't use separate format strings, or at least use type agnostic place-holders in the format string so that the type information is in one spot only. (the DRY design principle).
Re: (Score:2)
Writes the guy who has no clue about programming ...
Seriously, that was an absurd rant which puts you on my "don't hire such an idiot" list.
Re: (Score:2)
I thought for sure you were going to say Ada
Re: (Score:2)
He did! :P
But the spelling correction kicked in
Re: (Score:2)
If someone uses FOSS software, security for what they choose to use is their own responsibility. Contribute upstream if you think different. Otherwise, STFU.
Re: (Score:2)
I always enjoyed trying to find the weak spots in my code that could be vulnerable and then writing some brutal "fuck you" code to stop it and alert me if anyone tried to exploit it.
Every once in a while I get an email saying, "A user tried to pass some hack code to the function blah()..."
But your hobby might be painful? (Score:2)
Interesting FP and so modded, but...
So should you be liable if someone is damaged when your "hobby" code includes bugs? I'm sure that your intentions were good and pure and all that, and you just wanted to be generous by sharing your code, and you weren't paid for the hobby. Etc.
Asking for a friend, of course. (But now I know what to look for in the discussion.)
paperwork is boring (Score:5, Insightful)
Re: (Score:2)
This is a very good point, and I will add that if someone told me I should improve security by rewriting my project in a completely different language, I would laugh at them then ignore them. I focus a lot on security, but that's not going to happen.
Re: (Score:2)
I would laugh at them then ignore them.
When I first glanced that, I read it as "I would laugh at them then ignite them". I couldn't agree more.
I'm guessing the people saying that aren't interested in talking about a quote.
Re: (Score:3)
I will add that the security community sometimes declare things as horrible vulnerabilities, that are not.
In the news there was the big story about Nintendo's password lighting 'ok' without them actually submitting the password. Turned out it showed OK when a possibly valid password was entered, not having anything to do with the user's password. A 'security researcher' grabbed press for being completely in the wrong.
In another example, I saw a report go up against a web portal specifically designed to let
Re: (Score:2)
I see a lot of reports of "security flaws" that can only be replied to with "So what?". Like the one you mentioned with /etc/passwd. Call me when you can cat /etc/shadow.
Most web scanners generate page after page of so whats. Most of them involve the ability to get the server to quote back a bad parameter in an error message without any evidence that it had any effect other than generating an error message. Hint, if your 'HTML injection attack' generates an error message, it probably failed.
Re: (Score:2)
That reminds me of the first time I ever did an automated security scan, it found tons of "security problems" but upon investigation, most of them were just cookies in the browser from advertisers. Annoying, yes, but not a security flaw.
Re: (Score:3)
Being able to cat /etc/passwd is a security vulnerability in very many cases.
It gives you a list of usernames, which tells you what accounts exist that can be attacked. It can tell you what software is installed, which can suggest things to try to exploit. It can be a privacy issue, as it can contain names and phone numbers. It can be a starting point for social engineering.
Yeah, it won't get you in on its own, but that doesn't mean it can't be of great use to somebody looking to get in.
Re: (Score:2)
It's generally marked as world readable. The question of how bad that may be depends on the machine in question. It (as I suspect), a machine that allows a script like OP was talking about is actually a VM or a chroot jail, it's not at all a big deal and it isn't broken, so it doesn't need to be fixed. If it's the machine that holds the nuclear launch codes, having it on the net at all is bad.
The crux of it is that security is situational and some security researchers don't seem to know that.
Re: (Score:2)
No modern system has accounts - that could probably hacked - in /etc/passwd. /etc/passwd ... and I do not remember a linux system which had it hat way.
On my Mac the account are most certainly not in
Re: (Score:3)
The article is relatively clear about that:
"I find security an insufferably boring procedural hindrance"
Developers generally do not want to become security auditors; they want to receive the results of audits.
Instead, developers said they were purely interested in finding features, fixes and solutions to the open-source projects they were working on.
It doesn't seem to be a commercial intent here though.
No shit (Score:2)
You get satisfaction out of making some idea work, it's someone else's fun to make it secure. So yeah I guess we need more people to get satisfaction out of going through open source code and fixing or finding vulnerabilities. Maybe a better incentive system?
Re: (Score:2)
Very shallow definition of "making something work". If it's insecure, it's not really "working".
The current state depends from that second phrase attitude.
That would be money.
That's fine. (Score:3)
Let the volunteers do what they like and let the companies selling and profiting off of their work do the nitty-gritty boring stuff.
Re: That's fine. (Score:3)
Re: That's fine. (Score:5, Insightful)
You don't get it.
We are not doing this for you.
In fact, I'm only coding for me. Everyone else getting something from it is a mere side-effect. Don't count on it. I don 't care.
Re: That's fine. (Score:5, Insightful)
You don't get it.
We are not doing this for you.
In fact, I'm only coding for me. Everyone else getting something from it is a mere side-effect. Don't count on it. I don 't care.
A-fucking-men.
"This software is provided in the hope that it will be found useful, but without any warranty"
My time and attention is very limited. If you want me to care about your problem on your arbitrary schedule/deadline, you need to somehow make it worth my while. You consider your time to be valuable; why do you assume mine is not?
Re: (Score:3)
You don't get it. We are not doing this for you. In fact, I'm only coding for me. Everyone else getting something from it is a mere side-effect. Don't count on it. I don 't care.
A-fucking-men.
"This software is provided in the hope that it will be found useful, but without any warranty"
My time and attention is very limited. If you want me to care about your problem on your arbitrary schedule/deadline, you need to somehow make it worth my while. You consider your time to be valuable; why do you assume mine is not?
Good points. TFA points out that personal satisfaction is the main driver; and as a result developers will work on what interestes them. Unlike a job, where you may have to do boring things as part of the deal, people don't want to spend their free time doing things they don't enjoy if given a choice. To expect differently is an exercise in futility. That's the whole point of a hobby, to do what you enjoy for the enjoyment of the activity; not to meet someone elses needs. if you do, great, If not that's O
Re: (Score:2)
If you take code that someone else wrote and then sell that code YOU are responsible for that code. All of it. Even the parts you didn't write yourself. If I were you, I would invest some time checking over their work.
Re: (Score:3, Interesting)
I agree. I've spent a bunch of time screaming that inside commercial software development.
But it's very hard to get anybody to listen, because "checking over their work" is a very big project, and if you do it, you will be beaten to market and/or undersold by somebody who just grabbed that work and shoved it in without checking it over. And you will have no way of convincing the customer that you added more value than that competitor. So you may be out of business.
This is one of the many things that have le
Re: That's fine. (Score:4, Interesting)
We have a fix for this. Look at Android and iOS, loads of commercial apps, mostly badly written with little regard for security... And yet somehow we haven't gone back to the old Windows XP days of your computer being p0wned within milliseconds of connecting to the internet.
It's because those operating systems provide well debugged libraries with decent security, and then layers of sandboxing and limited permissions on top of that. They are safe environments for bad apps to run in.
Sure they aren't perfect, stuff gets through sometimes, but they show us how we can fix this problem without auditing and fixing every single application or somehow convincing people to work for free.
Re: (Score:2, Insightful)
We have a fix for this. Look at Android and iOS, loads of commercial apps, mostly badly written with little regard for security... And yet somehow we haven't gone back to the old Windows XP days of your computer being p0wned within milliseconds of connecting to the internet.
It's because those operating systems provide well debugged libraries with decent security, and then layers of sandboxing and limited permissions on top of that. They are safe environments for bad apps to run in.
Sure they aren't perfect, stuff gets through sometimes, but they show us how we can fix this problem without auditing and fixing every single application or somehow convincing people to work for free.
We would still be better off if all software was open source. For a start, we wouldn't be completely screwed if the seller abandons the product or goes bust.
Re: (Score:2)
I agree.
Re: (Score:3)
If I have to fix it before it's usable then I may as well just do it myself
Okay, so then do it.
Wait, you're posting to slashdot while waiting for someone else to do it, and that was just hot air?
Imagine my shock and surprise.
Re: (Score:2)
As usual (Score:2, Offtopic)
Software is about 20% coding and 80% maintenance.
Supporting some junk you wrote for yourself, for yourself, is easy.
When you post your code (usually to be helpful) on some software site, and the support/bug requests from "users" starts to build up is probably the main reason people abandon their efforts.
These people do not have what it takes (Score:2)
Sure, that mindset is fine for writing no-consequences, hobbyist code. But anybody that wants the prestige that comes with contributing to a real project better check their assumptions.
"Audits"... (Score:4, Interesting)
There's something wrong with that. The center of attention is in the wrong place.
The whole idea is that you write the thing to be secure to begin with; the security is part of the fabric of the whole construction. Audits are secondary, however useful they may be. If you think of security as an auditing or testing process, all your audits or tests will do is tell you that you don't have security. ... and, really, you can go a long way toward being secure just by being correct for all possible inputs. Which is actually kind of an interesting challenge if you approach it on those terms.
I'm not saying it'll appeal to everybody, but at least for me, and I suspect for a lot of people, there's a lot more appeal in trying to capture perfection in your code tp begin with than there is in auditing anything, let alone responding to audits. Procedural stuff like that does indeed suck, and I know; it's been a big part of my life.
Re: "Audits"... (Score:2)
You sound like the idiots who say "why do we need QA? Just don't write code with bugs!"
Re: (Score:3)
Security audits have taken on a life of their own, a for-profit subfield that defines itself as autonomous (and not without some compelling arguments) that almost values the heft and size of its reporting over the quality of its contents.
I've worked for a company that has gotten into doing security audits and its kind of sad how focused it is on the length and volume of its reports, too often filled with trivia details and garbage data that nobody will read and few will take away any meaning from. I've sta
You get what you pay for (Score:3)
People should be happy that they are even trying to secure their code, without getting paid to do it. I bet any demanding clowns want a free pony for every download of a Linux distro.
It's mostly social pressure mixed with a bit of pride that drives FOSS developers to secure their code in the first place.
Long story short, if you expect near 100% secure code, better be ready to open your wallet wide.
Low bar (Score:2)
On the assumption that recognition is important for the writers and that reliability is important for the users the solution would seem to be some sort of certification process for FOSS. Just as Google Play has reviews and star ra
s/Open Source// (Score:2)
I'm afraid this doesn't only go for Open Source developers.
- Hubert
Temperamentally unsuited to coding (Score:2)
Many years ago, I was hitchhiking and got a lift with a developer. We got talking about programming, and the amateur stuff that I had done at university.
I said something like "I liked writing programs and solving problems, but I can't type well enough. Often I just compile the program and let it find my typing errors . ." The driver laughed and said I was temperamentally unsuited to be a programmer.
In my career I did a lot of security audits working with development teams. I must have heard every excuse
Lack of gratification (Score:2)
The thing is, even kids like doing chores when there is a gratification waiting at the end. Gamers will grind for hours just to get it. So it's not an impossible task, but can be made into a rewarding one.
Management needs to bind the process to the contracts and make developers understand that when they go through these chores that it directly translates as money onto the table for everyone.
So did past management of mine always define exactly the customers' requirements in contracts, down to every single la
Closed Source is the Same (Score:2)
IME, management have to lean on developers to do security testing at least as hard as they do to get them to document stuff. Yes, even paying them isn't enough (unless they happen to be a security-fanatic). Add to that the problem of "security audits" performed by consultants who throw standard test sets around without worrying about context ("Yes, we have port 80 open - it's a website. Yes we could encrypt our opening times but the thing is, they're not secret. That's why they're on the public website.") a
Re:Open Source = Never Corporate (Score:4, Informative)
This is exactly why open source systems will never go mainstream. In environments that require routine security testing, patching and vulnerability probing, open source fails. That means NO open source in PCI, HIPAA, CJIS or NIST type required infrastructure.
You forgot the sarcasm tag.
Re:Open Source = Never Corporate (Score:4, Informative)
"That means NO open source in PCI, HIPAA, CJIS or NIST type required infrastructure."
That's absurd. I don't work with CJIS or NIST, but LOTS of PCI and HIPAA related infrastructure uses open source software. Those are ongoing processes that can be applied in any environment using pretty much any tools.
"In environments that require routine security testing, patching and vulnerability probing, open source fails."
Because you can't test or probe open source software? What are you on about exactly?
Re: Open Source = Never Corporate (Score:3)
And you nirjobs still thonk we *want* to go idiotstream.
Yet, still you're typing this in a open-source browser, probably on a open-source OS and kernel, talking to servers running nothing but open-source software.
Accept it. We have won. Social ape behavior has won over own-baby-eater lizard behavior.
Re: (Score:3)
This is exactly why open source systems will never go mainstream. In environments that require routine security testing, patching and vulnerability probing, open source fails..
That's why you never find applications like Apache, nor operating systems such as BSD or Linux used in secure corporate environments - or for that matter languages like C, perl, or python. /sarcasm
Man, I really hope you were kidding... but your comment sounds like you were serious.
Re: (Score:2)
There is open source in HIPAA type required infrastructure, just fyi.
Re: (Score:2)
This is exactly why open source systems will never go mainstream. In environments that require routine security testing, patching and vulnerability probing, open source fails. That means NO open source in PCI, HIPAA, CJIS or NIST type required infrastructure.
Not true. Drupel, for example, can be used to build HIPAA compliant sites.
Re:Yes, but ... (Score:5, Insightful)
Being a lead systems analyst I find no excuse to those people who don't want to do their job right.
if "those people" not being paid to do it, then it's not "their job" to "do right".
Once you start paying them, then you get to tell them how to "do their job".
Re: (Score:2)
Thinking how things should be isn't a contribution to anything. I think nobody should rob a bank. Do I get points for having a good idea?
Re: (Score:2)
Yes, it is boring. But it IS an essential part of the job
But it isn't a job. As it stands those people who manage FOSS have very little leverage over the developers who create stuff voluntarily. They can only hope to persuade, they cannot coerce.
We have known this for decades - just look at the state of documentation for many FOSS offerings. Individuals, creating software on their own time will only continue doing so if it is emotionally rewarding for them. They like the creative part - new features and functions. But they find the rest a chore.
They also have
Re: (Score:3)
Security has to be designed in the product from the beginning, it can't be bolted on as an afterthought.
Re: (Score:3)
Ideally, bad code should not even be possible in the environment you code in.
If bad code is impossible, then good code is nearly impossible.
Re: (Score:2)
Re: (Score:2)
"The open source model is flawed. Fatally. It provides no real mechanism for developers to make a living selling their code (and coding, not support, is what motivates developers). "
Do you see the contradiction?
In other news, selling apples is flawed. Fatally. Selling apples provides no real mechanism for orange producers to make a living by selling oranges.
As you say, developers want to code, not selling code. Therefore, they should be payed for writing code, not by wherever the code goes once written.
I