|
I prefer to call them suggestions. and if I wanted suggestions for my code, I'd just out-source it.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
To the knife.
Software Zen: delete this;
|
|
|
|
|
Compiler warnings should never be ignored. If you ignore them, they build up and eventually obscure things like: "Unable to resolve reference to x as it was built with a higher framework version". This is just a warning, but try and publish such an application and you will quickly find it does not work in production. The number of times I am asked to help someone solve an issue which they could have solved themselves if they just read the warnings...
|
|
|
|
|
The only warnings ones I (usually) have are "returns" used to "disable" code meant for (eventual) deletion. So, I guess I do take notice when it's something else. They eventually get cleaned up; mostly unreferenced variables. Probably an OCD thing.
(Someone once noticed I had left an unused namespace in my XAML ... while I was developing; and felt they needed to bring it up).
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
|
|
|
|
|
We are in the process of introducing the Coverity static code analyzer. It is very good at telling you why it warns you ("If [this] occurs, and then [this] and then [this], then you follow a null reference at [that] line" - the series of inferences may jump from source file to source file, and may go in five or six or more steps).
For this discussion it is more important that it maintains a history of all the "defects": If you have once reported that a given defect is in intentional, at the next Coverity run it will not be reported again. Same if you have flagged it as a false warning (which may occur if you set the agressiveness level to "high"). So you won't have the same warnings again and again. That makes it much more realistic to handle even moderate risk defects, because you do it once only. And if you give it a verdict of "intentional" or "false warning", you can leave it in your source code as it is.
Actually I am a little bit in love with Coverity at the moment. I never seen any compiler or other code analyzer that comes close to it neither in its ability to detect defects, nor its flexibility in handling them. The big disadvantage is that your billfold will complain loudly ... And it takes some heavy iron (or lot of patience). But when you employer can afford both the software and the iron, then it is great.
|
|
|
|
|
So I sat together with a client yesterday, they wanted some web application replaced.
He logs in with an admin account and gets on a page of all users that he can impersonate.
But why impersonate because... All passwords are stored AND SHOWN as plain text!
Forgot your password? Give us your email address and we'll send you your password, easy.
Oh yeah, and if you're not in the database we'll let you know so you can check if your competition is using this.
At least it's not the user's own password as the only way to get an account is... Actually, we couldn't find out, but some admin should create it (and the password I guess).
We did find how to reset a password... Change it directly in the database.
All this on HTTP without even the option for HTTPS.
As you can imagine, this wasn't the only thing that's wrong with it (don't even start on usability)...
I kind of assumed it was a quick and dirty intranet application, but it's on the public internet and apparently (business) customers are using it.
So... Should I keep these features when I rewrite it? 
Makes you wonder exactly how unqualified some people are for their job (or maybe this programmer wrote it exactly according to specs?) and that stuff like this happens everywhere.
|
|
|
|
|
Sander Rossel wrote: (or maybe this programmer wrote it exactly according to specs?)
The project spec sheet:
- Ensure that even non-hackers can trivially access your system in unexpected ways.
- Ignore best practices as often as possible.
- Confuse actual hackers by making them think it can't possibly be this easy.
- Just make it really, really dumb.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Or:
1. We want full control over the system, including passwords because we know better.
2. We want to be able to log in as any user for testing purposes.
3. Changing passwords is a hassle and not user friendly, so just mail it to them.
You know how managers pointy haired bosses think (if at all) 
|
|
|
|
|
Doesn't cover the full range of findings.
I'm going to point back to what Uncle Bob said back when the VW testing scandal occurred: it doesn't matter what management wanted, the issue is that programmers did something knowing it was unethical.
Now, this of course brings up the question if ignoring security is unethical. I'm going to say yes, but I'm a bit biased on this one, since I multi-hat as a dev, security analyst, and backup SA.
Maybe @chris-maunder could make a poll out of that one 
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Nathan Minier wrote: if ignoring security is unethical
Maybe this programmer didn't ignore it, but simply didn't know about proper user and password management.
Or he knew, but didn't have the skills to implement it, and was afraid to ask for help because it would cost him his job.
Or he thought he knew, but obviously didn't.
I'm not making excuses, this guy should find another career asap.
I'm just saying we don't know the full story.
The only thing we know is that one or more people were not ready to take on such a project 
|
|
|
|
|
Sander Rossel wrote:
Why, as I saID TO ONE COMNPANY TRHAT WANTED TO HIRE ME:"i'VE MADE A PRETTY NICE CARREER OUT OF CLEANING UP AFTER THE MESSES YOUR COMPANY LEFT.i THINK i'LL JUST STAY HERE AND CONTINUE UNTIL YOU OFFER ME A POSITION IN CHARGE OF NOT LEAVING THE DISASTERS IN YOUYR WAKE.
Surprisingly, they agreed with me, unsurprisingly, they never called back again.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
i need user managemnent coez, snd urgend plz.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Nathan Minier wrote: Maybe @chris-maunder could make a poll out of that one
Sure! Send me some thoughts and I'll whip one up.
cheers
Chris Maunder
|
|
|
|
|
Problem is: if a developer ignores security it is unethical. If a developer knows Jack and sunshine about security, and Jack left town...
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Then that's not a developer; because a developer would do some research while assessing requirements. That's a random dude doing C&P from SO, and has behaved unethically by misrepresenting themselves.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
And you're right, except that a lot of "developers", either with engineering degrees or those certificates "become a Web Developer in 1 month and find a job" are actually certified developers.
Yet they do know less than 0 about developing, security, architecture and whatsnot.
Also, managers will invariably check out the prices of professiona, deem them too high and then have the work be done by their nephew who "knows computers".
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Well, the losers will keep the rest of us employed, I suppose.
I'm just worried that if we don't start policing ourselves, various governments will start to do it for us (like PCI-DSS, HIPAA, or GDPR have for the industry at large). That way lies madness.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Madness is unavoidable either way.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Sander Rossel wrote: 1. We want full control over the system, including passwords because we know better.
2. We want to be able to log in as any user for testing purposes.
3. Changing passwords is a hassle and not user friendly, so just mail it to them.
You know how managers pointy haired bosses think (if at all)
This. I've seen a spec for a system that was remarkably similar to this (if somewhat wordier).
The key theme was: Management er.... pointy haired ones, must have ultimate and full control.
|
|
|
|
|
Sander Rossel wrote: Makes you wonder exactly how unqualified some people are for their job (or maybe this programmer wrote it exactly according to specs?)
Hanlon's razor:
Never attribute to malice that which is adequately explained by stupidity. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
Speaking of that. Whatever happened to Dalek Dave?
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Quote: Hey Lord don't ask me questions, Hey Lord don't ask me questions
Hey Lord don't ask me questions please!
Hey Lord don't ask me questions, Hey Lord don't ask me questions
Hey Lord ain't no answer in me.
|
|
|
|
|
Very clever. A hacker pops in, looks at it, and says "Yeah, right. Like I'm gonna fall for that," decides to try hacking some other site.
|
|
|
|
|
Sander pops in, looks at it, and says "That needs a complete rewrite."
So basically any new programmer on any old project 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
