Apple Security Blunder Exposes Lion Login Passwords In Clear Text 205
An anonymous reader writes "An Apple programmer, apparently by accident, left a debug flag open in the most recent version of its Mac OS X operating system. In specific configurations, applying the OS X Lion update 10.7.3 turns on a system-wide debug log file that contains the login passwords of every user who has logged in since the update was applied. The passwords are stored in clear text."
Great (Score:5, Funny)
now i can find out what my password is.
ive been resisting a reboot for ages!
Re:Great (Score:4, Informative)
Re: (Score:2, Interesting)
Oh hi there, InterestingTechGuysIn140Bytes. I was kinda wondering when you'll get a next account after you've blown last [slashdot.org] previous [slashdot.org] three [slashdot.org].
Re: (Score:2)
Google already has everything about you. There are barely laws that protect you about the gathering google does. why complain about the plain text part?
Re:Great (Score:5, Informative)
In this case, because it is a false allegation. He should read the article he posted (and so should you)
Re:Great (Score:5, Informative)
Yes, because having a known md5 hash to transmit in plain text is much more secure than having a known password to submit in plain text.
If you want to do this properly, you use SSL for login (and possibly more) or you implement a secure password exchange protocol (e.g. SRP).
Re: (Score:2)
No, they can't try the same password somewhere else, but they can click "I forgot my password, email me a reset link" anywhere else.
Re:Great (Score:5, Interesting)
You obviously have no fucking clue of what you're saying. If you hash the pass before sending, then what happens if someone sniffs the connection? They can just send the hash!
The hash effectively becomes the password.
So no, it doesn't increase security. But you know what does? Two-factor authentication. And do you know what big consumer oriented company start offering those first? I'll give you an hint [google.com].
Re:Great (Score:5, Informative)
The hash effectively becomes the password.
Come on now, nobody simply hash the password: you timestamp it and salt it first then hash it. That is how it is done, and you know it. So yes the parent is incorrect, but saying that hashing is useless is misinformation. If you properly hash, a sniffer will be able to use the hash as a password only once. So that is a man in the middle, that sucks but it is not a complete pwnage as you suggest it is.
Re: (Score:3)
I never said hashing is useless. Hell, the Google Authenticator that I linked does exactly that (HMAC-SHA1 with the Unix timestamp as the message).
I said that an hash of the password is useless, and it is. An hash of pass+timestamp+salt is not the same thing as an hash of the password.
timestamp it and salt it and then hash it? (Score:5, Insightful)
First, if you timestamp it, you don't need to salt it. The password would effectively have a lifetime of minutes at best, so adding a salt doesn't improve anything.
Second, your idea ruins the whole point of using a trapdoor function (what the internet means by "hash"). The point of the trapdoor function is that the server doesn't have to have your password stored on it, because you can just verify the password presented by comparing a hashed form of the presented password to the hash you have stored.
But with a time+password hashing scheme, the server must know the user's password because each time the user logs in, the must construct a new hash from the password and the current time.
So, if your server is going to know the password, just use a shared secret system like SRP. Then you get two-way mutual authentication too.
Re:timestamp it and salt it and then hash it? (Score:4, Insightful)
The point of the trapdoor function is that the server doesn't have to have your password stored on it, because you can just verify the password presented by comparing a hashed form of the presented password to the hash you have stored.
But with a time+password hashing scheme, the server must know the user's password because each time the user logs in, the must construct a new hash from the password and the current time.
Not true. The server can just store the salt + hash of the password. Then when a client wants to authrenticate the server sends the salt + random one-time value. The client uses the salt to generate the password hash. Then it concatenates the random value and resulting hash and hashes the whole and sends the result to the server. The server too computes the hash of the concatenated random value and password hash. It then compares that with what the client submitted. If it matches then the client had the right password. The hash sent by the client cannot be used for replay attacks because the random value will be different for the next login. The server does not know the user password and the hash is salted making it hard to recover the user password (which helps if it was used on other sites). The stolen hash can however be used to authenticate through the login algorithm however.
There's probably better solutions but this is enough to prove the server does not have to know the user password even if timestamps or one-time random values are used.
Re: (Score:2)
How does a timestamp help? You either need to ensure the client and server are in lock step, and adjust for transmission delays (impossible), or you allow a window +/- a number of seconds for the timestamp to arrive at the server, thus making replay attacks possible.
Presumably the timestamp and salt is sent along with the hashed password.
However this does not prevent phishing and code injection style attacks. That's the real problem SSL is trying to solve, namely that any site with a SSL certificate is who they claim to be, and that no one in the middle has slipped in something extra during the download.
Re: (Score:2)
Actually, timestamped hashes like Google Authenticator uses can be easily used to prevent phishing: after you log in with a generated code, you wait for the next code (30s using GA) and then the server shows the new code to the user, authenticating itself the same way he did.
It doesn't protect you from MITM, though.
Re: (Score:2)
Which is good enough for most sites I guess. It's also in one way more secure than SSL, as instead of the site proving itself to you; it's you proving yourself to the site. IOW if someone steels a user’s PW, SSL won't prevent the theif from logging on with it.
Re: (Score:2)
Google Authenticator "cheats" a bit by using your mobile phone to first authenticate that you aren't some password stealing hack.
What do you mean? I don't use GA itself, but a J2ME app that implements the same algorithm, so I wouldn't know what kind of verifications GA does, but Gmail et all work fine with a basic HTOP/TOTP implementation.
Re:Great (Score:5, Informative)
Protecting against replay attacks is easy: don't allow two logins to the same account in the same window of time (30s, using Google Authenticator).
Most people won't login twice in 30s anyway, so they aren't affected.
malware (Score:4, Funny)
apple even ships their own malware.
Re:malware (Score:4, Insightful)
considering how this only affects people who used FileVault encryption on their Mac prior to Lion, then upgraded to Lion but kept the folders encrypted using the legacy version of FileVault, I hardly think this will be a popular vector for any attacks, malware or otherwise.
Re:malware (Score:5, Funny)
Re: (Score:3, Informative)
People who actually want security wouldn't be using an older, and slower, version of FileVault in the latest OS and also ignoring the message telling them to upgrade the FS to the latest version.
Re: (Score:2)
I don't have a Mac because I kind of enjoy participating in the anal retentive guild of digital grooming. Inference from logic shouldn't be u
Re: (Score:2, Insightful)
Slow down here chief, these aren't Linux users you're talking about. Apple'a upgrade is easy. It asks if you want to upgrade the encryption to match Lion's. If you said no, then you're exposed since you're using old code. They're not asking you to recompile your kernel here. I've never met anyone serious about encryption who stays versions behind.
Re:malware (Score:4, Insightful)
The problem with Linux and generalizations is that there's more than one Linux.
I've never recompiled a kernel (that I'm aware of).
Re:malware (Score:5, Informative)
Oh yes, you're right. It sounds like it only impacts people who actually want / need security. So that's OK then.
No, because the people who actually want/need security would have already turned off the legacy FileVault (i.e., the one that only encrypts the user's home directory leaving the system directory where the log file in question is located unprotected) and turned on the new FileVault which encrypts the whole disk, including all system directories. That was one of the few really compelling features of Lion.
BTW, this is a Mac OS X 10.7.3-specific issue. It does not affect users of pre-Lion systems which only have the legacy FileVault option.
Re: (Score:2)
For a multi-user system, some people might argue that the old FileVault provides marginally better security because it protects each account's data with separate encryption keyed to the user's password, which means that even if someone manages to find a way around the permissions model, your data is still protected except while you are logged in and the volume is mounted. Whether this outweighs the loss of encryption on the rest of the system (swap, etc.) is debatable, of course.
If you are really concerned with security of your data in a multi-user system you will have the really sensitive data in an encrypted disk image (using Apple's Disk Utility or TrueCrypt or something similar) regardless of whether the whole disk, just your directory, or neither are encrypted. And that's precisely for the reasons you cite: you can't prevent the other users' accounts from getting compromised.
Re: (Score:2)
People who actually want security are more likely to have upgraded to filevault 2 when they upgraded to lion, i certainly did as did everyone else i know who is running lion.
Re: (Score:2)
Maybe it wasn't an accident. (Score:2)
Underhanded C contests prove that it's possible to slip a bug into a critical piece of software in such a way that it looks like programmer error. This allows for plausible deniability from the company (Apple).
http://en.wikipedia.org/wiki/Underhanded_C_Contest [wikipedia.org]
Ouch! (Score:2)
It's a good job that my password is also the combination to my luggage.
In before "lol Mac users deserve this".
That makes for quite the dangerous security breach.
Do they have a build process? (Score:5, Insightful)
When I build a system for Linux distribution, I use scripts to configure the options on the build server. I don't use manually specified configurations from developer workstations.
Doesn't Apple grasp this concept of source code versioning and build management? Or was the debug flag in question hard-coded in the source rather than specified as a build option? If so, Apple needs to revisit it's coding structure and figure out how to set BUILD TIME options instead of hard coding them.
Re:Do they have a build process? (Score:5, Informative)
Well I've seen many logging frameworks where debug logging and application logging was simply a different severity level, particularly since you may want crash/debug logs from users. All it takes is one sloppy developer that needed a log output, copy-pasted an application log line instead of a debug log line, because it's only temporary and you're going to take it out right? Both works for him. And then suddenly you end up with debug info in your production logs. I don't see why this would have to be a problem with their build process.
Re:Do they have a build process? (Score:5, Interesting)
Like:
#ifdef DEBUG_BUILD
SaveDebugInfo(logfile);
#endif
But if the developer had not bracketed their code with proper protection macros, no build setting is going to rescue you.
I have tried make the system as automatic as possible. I have laid down rules to my team. But if you make the system very very foolproof only fools would be able to use it. The process requirements will swamp out the developer. Most likely the error happened at several stages. Originally a function that will be called only under debug build was making a call to save stuff to the log file without protection because the whole damned function is supposed to be called in debug mode. Then someone cut/paste parts of the code out to a function that is called in both debug builds and protection builds. Carelessly.
There is no way you can protect yourself against careless developer. Anyone working at such sensitive parts would be a senior developer, probably a manager stepping in to fix something simple in a module that he himself wrote ages ago. He was very confident and the build guidelines might have mutated without him knowing it. #ifdef DEBUG_BUILD might have been changed to #ifdef DEBUG_OSX and #ifdef DEBUG_IOS and he never got the memo because he was not a regular developer. Such things happen.
Re:Do they have a build process? (Score:5, Insightful)
There is no way you can protect yourself against careless developer.
Of course there is. It's called "code review".
Re: (Score:2)
Re: (Score:2)
Reminde me of this: http://www.reddit.com/r/programming/comments/lchhd/ban_programmers_not_functions_about_memcpy_s/ [reddit.com]
Re:Do they have a build process? (Score:5, Insightful)
That's option B, option A is called "Open Source".
Which works as a distributed form of... wait for it... code review.
Re: (Score:2)
That's option B, option A is called "Open Source".
Just playing devil's advocate here, but are you saying that Open Source code is immune to bugs like this?
Re: (Score:2)
Because open source has proven to be immune [c2.com] to such things? Puhlease...
Re:Do they have a build process? (Score:5, Informative)
All your debug flags and compiler flags and build settings etc assume the developers would properly bracket their code under proper #ifdefs .
It's safer to bracket the logging code in #ifdefs:
so that you only have to get it right one time. If you make developers repeat a process 10,000 times and they get it perfect 99.9% of those times, that means it's still screwed up in 10 places.
Re: (Score:2)
Re: (Score:2)
I agree. The bug itself is a problem, but the real problem is that this was apparently easy to get wrong. And there, Apple has shown to be on low amateur level. Getting something as serious as this wrong must be hard enough that it only happens by intention and that intention needs to be expressed clearly and subsequent warnings must be in place.
So, yes, they have some sort of build process, but not designed or implemented by people that know what they are doing. Alternatively, the people designing the debu
Re: (Score:2)
Doesn't Apple grasp this concept of source code versioning and build management?
Its not just apple (if this is even the case), its an amazingly huge number of "software" companies out there. For some reason, the idea of enforcing coding rules for debug flags and the like, along with enforcing a proper build system seem to escape a large (i'm guessing well over 50%) percentage of developers out there. I've seen/heard about it time and time again, where the build going out the door is the one generated on so
Do you want to find the passwords of other users? (Score:5, Funny)
As an InfoSec pro... (Score:3)
This though...bitten by a debugging flag, the dev must be hitting the sauce right about now.
Now, putting my coder hat back on, why was a debugging flag left enabled while building for production?
That's just lazy/bad setup, everyone knows that you keep your environments separate.
Re: (Score:2)
The real problem is that the debug flag could mess things up this badly, apparently without it being readily obvious. Logging passwords is something you should never be able to enable this easily. If really needed, you hard-code debug instructions for secret info and so that it immediately obvious and includes drastic warnings. Like a screen-output you cannot suppress or something like it. Then you remove it after you fixed the problem. Secret information has absolutely no business at all appearing in ordin
I wonder what the comment said... (Score:3)
Re: (Score:2)
Re:I wonder what the comment said... (Score:5, Funny)
//REMEMBER TO COMMENT THIS SHIT OUT SO I DONT GET FIRED
Filter error: Don't use so many caps. It's like YELLING....
Bad news - but for a very small subset of users (Score:2)
Anyone who used FileVault encryption on their Mac prior to Lion, upgraded to Lion, but kept the folders encrypted using the legacy version of FileVault is vulnerable. FileVault 2 (whole disk encryption) is unaffected.
I can see how those circumstances could occur in the real world; however the first version of FileVault was a pain, and I don't know of many people that kept using it for very long.
I stopped using FileVault v1 after a few days. What sensitive stuff I have is now in encrypted sparsebundles, with the rest of my stuff unencrypted. Time Machine backups are stored on a LUKS-encrypted disk.
FWIW I've stuck with Snow Leopard - not a real fan of Lion. That was another thing I stopped using after a few days, although
Re: (Score:3)
I wasn't a fan of Lion either after only a few days. It still has some things that have changed over SL that I really wish were back (Save As..., the old version of Preview, etc) but I did grow to like it much more when I got a Magic Trackpad instead of using a mouse. I think a lot of my issues stemmed from accessing it with a mouse. It's been designed (for better or worse) with trackpad users in mind.
Still, I can't really say it's been a step forward for OS X over 10.6 - it's a bit of a wash from a persona
Re: (Score:2)
It depends on the person. Lion changed a lot of things, and not everyone will be happy with those changes. Personally, I absolutely love Lion, except for the way that Mission Control clumps application windows together (at least you can enable App Expose). I even really like the new way Spaces works; I use it so much more now than I used to.
As for this bug, it's a stupid mistake, but at least one that will hit a very small set of users. It's silly not to have upgraded from FV to FV2, and most people did
Re: (Score:2)
You'll love Mountain Lion then - the exposé behaviour is going back to the pre-Lion way with a setting toggle in preferences. I know several people who wanted that back.
The specific configurations (Score:2)
Not really (Score:5, Informative)
FTA:
So only certain configurations, and relatively few at that.
Relatively few? (Score:5, Interesting)
What qualifies that statement? Any FileVault user that upgraded to Lion would be affected, which I would think would be more than a few. FileVault is not upgraded to FileVault 2 automatically. The user would need to manually disable FileVault and then re-enable it to get the whole disk encryption feature.
Re: (Score:2)
Lion suggests that to you when you upgrade if you have the old version of FileVault running.
We have QA processes which automatically detect (Score:5, Insightful)
Does Apple have no such thing? This leads me to think that Apple either has no development lifecycle or, in case they have one, only half-heartedly obey it.
Re:We have QA processes which automatically detect (Score:4, Insightful)
I've been working here and there for Software Verification for a number (double-digit) number of years, on a number of products. I've seen programmers do some things in development that they forget to clean out before release that would curl your hair. Especially from the ones fresh out of school, who don't have a lot of experience. "Oh, I'll put in these debug lines just for now." No wrappers or conditional compliation of any kind, so they leak out into the final product with no one the wiser.
Another commenter pointed out that a proper assurance test would look for rogue files. That works for unauthorized/unspecified log files, such as in this case, if the organization has good specifications and tight testing. I'm not in a position to comment about Apple's coverage in this area. The problem is that other debug statements could make unauthorized entries into authorized logs, and who would catch it?
What I saw was most effective was peer code review, especially if you had the coder equivalent of the BOFH in the audience to catch crap like this. There's nothing like people seeing "release" code with debug stuff not stubbed out.
Re: (Score:2)
things such as debug logs during testing
Even rpmbuild will refuse to write a package with extraneous files, but it seems likely in this kind of situation that the log file wouldn't be present until runtime.
Probably SELinux can prevent this situation.
Re: (Score:2)
things such as debug logs during testing.
Does Apple have no such thing? This leads me to think that Apple either has no development lifecycle or, in case they have one, only half-heartedly obey it.
I think that a company that has been able to pull off a virtually seamless architecture and word-size change like Apple did with OS X probably has their development methodology pretty well, er, developed, don'tcha think?
But Apple are perfect, so of course... (Score:3)
...you're passwording it wrong.
Ad the log file in question is ... (Score:2)
Comment removed (Score:5, Funny)
Re: (Score:3)
Copying features from Microsoft [microsoft.com] products again.
And ripping off open source [slashdot.org] without credit.
Don't blame the one guy still working on OS X.! (Score:5, Funny)
All of his friends went over to work on iOS and he's been left to pick up the slack. ;)
Re:Don't blame the one guy still working on OS X.! (Score:5, Funny)
Oh, and I thought everybody was working in the legal department.
What a pain! (Score:2)
Now I will have to change my password from "password" to "12345678."
--
A woman once said to Adlai Stevenson, "Every thinking person in America will vote for you," to which Stevenson replied, "That won't be enough, ma'am, I need a majority."
How soon until a fix? (Score:2)
Because this is problematic if one's login password on a mac happens to be their login password for everything else inside of one company.
Odds are that firewalls will protect outsiders from being able to snoop, but what's to stop somebody on the inside from doing a little covert snooping to discover the administrator's password, and using that to his own advantage in some way?
I would rather hope that Apple addresses this issue before the work day commences tomorrow, because now that this vulnerability
Just a bug (Score:5, Insightful)
Somehow I have a feeling that if this same kind of "bug" had been found in another operating system, such as one coming from Redmond, the discussion and media coverage would have been quite different, and there would have been much more Slashdot comments on this story.
We are talking about passwords stored in clear text, no fix yet, and based on the article, no assurance that the fix would remove copies of the unencrypted passwords. For a company that was wondering how to spend 100 billions. What a joke.
Re: (Score:2)
I've seen several non-Apple tech news sources pick this story up. They sure do love a good "Apple goofed" story.
I think the only reason it hasn't gotten more play is because while this is a serious bug it isn't one that affects a lot of users. It only affects those who have upgraded from an earlier version of OS X and have chosen to continue using the old version of FileVault instead of upgrading to the newer whole disk encryption one.
It's a feature. (Score:3)
Specifically, at each login. And logout. And several times in between. Quick! Keep changing it!
So staying with Snow Leopard WAS smart afterall! (Score:2)
After a year of having to endure "Your old Mac Core2 Solo 32bit can't RUN 64bit-only Lion! Loser!" comments, now, NOW I can say, there is a darn good benefit to staying behind the times! This security issue does not affect me!
This totally refills my Apple User Smugness supply.
What Slashdot Posters Hear (Score:2)
Re: (Score:2)
It's not there for me (Score:2)
Re: (Score:2)
Actually, Lion's FileVault is not a problem. Only if you were using the old FileVault from previous OSes (which only encrypted the home folder), upgraded to Lion, but did not switch to the new full disk encryption FileVault for some strange reason.
Re:lucky for me... (Score:5, Interesting)
Some "strange" reason?
How about you've got multiple users on the machine? With Filevault2, any user can unlock the whole disk. As much as I like macs, it's a complete joke. With Filevault1, you had homedir encryption on a per-user basis. My files were secure from other users of the machine.
Re: (Score:2)
That's what encrypted sparsebundles are for, surely (that you can mount at login).
FileVault 2 assumes that multiple users of the same system are mutually trusting of each other. It was not really meant to service multiple users - that's how version 1 worked and it had nothing but issues.
Re: (Score:2)
My files were secure from other users of the machine
The way I see it, the technical difficulties -- both manifest and potential -- of protecting users from each other on the same OSX system made FileVault 1 untenable. Every app (written by Apple or not) that put data into unprotected memory, swap, or disk was in principle leaking confidential information from the vault. You may have felt like your files were safe, and if you never turned on remote login or allowed fast user switching you were probably right, but the general multiuser case is full of attac
Re: (Score:2)
Re: (Score:2)
Re:bloody hell (Score:5, Interesting)
Looking at the actual message, it looks like the dev in question just took an "attributes" NSDictionary argument and stuck it into his NSLog() call whole hog, as in:
NSLog(@"about to call _premountHomDir with %@", attributes);
"%@" in an OSX printf-style format string will call -(NSString *)description on whatever object in on the vararg position for that %-code, and put that string in the output. The "description" selector on a dictionary spits out the keys and values of the dictionary in a human-readable format. The "attributes" object in this case contains a lot of information that would be interesting for a human debugger, the password being an exception.
Re: (Score:2)
If the test is checking log files, it's 1) not a unit test and 2) broken.
Re: (Score:2)
Indeed. Secret info in log-files is also a decades old problem. Any competent software developer knows about this and any bright person will figure it out by themselves. Guess the developer(s) in question are neither bright nor experienced. ElCheapo software development at its best.
Re: (Score:2)
Much as it probably is hard for people to acknowledge, Apple doesn't hire the best and brightest. Historically, like Microsoft, they have bought in most of their 'innovation.'
They spent many many millions of dollars trying to produce the 'next generation Mac OS (tagilent, pink, whatever including the one they called sagan until Carl Sagan sued them then they changed it to BHA (buttheaded astronomer..))
Then they gave up because their staff apparently was only producing botique crap and was much more interes
Re:Really? (Score:5, Informative)
Your login password also unlocks the encryption password for FileVault. The login passwords were apparently logged in a file outside of the encrypted image. (Only for the old pre-lion version of FileVault running under Lion)
Re: (Score:3)
No, it's off by default, and if you don't use FileVault (the legacy version) you are effectively not effected - your disk is not encrypted to begin with, and thus starting the machine in target disk mode gives access to your home folder to an attacker (or they can reset your login password with the OS X installer), bit *not* your keychain password which is the same by default, but not if the login password is changed via the root user or another admin).
It's still a bit of a huge security blunder though.
Re: (Score:2, Offtopic)
You are wrong my friend. It's your disbelief that makes you see us sitting down but in reality we do no such thing.
Re: (Score:2)
No. *Now* it can be avoided. Tests are for known (and therefore fixed) security problems, so they are only good for checking if the same bug is back. What happens in software development disturbingly often.
Re: (Score:2)
Although I'm not particularly a fan of Test Driven Development, you could have created some sort of 'debug flag disabled in release build' test the moment you decided to log passwords in clear text. You can even create a general rule like "Everytime you decided to weaken security for debugging purposes you should create a test that confirms this code will not be included in the release build". But yeah, without knowing much about their build process, its just pure speculation at this point and anyone can te
Re: (Score:2)
Although I'm not particularly a fan of Test Driven Development, you could have created some sort of 'debug flag disabled in release build' test the moment you decided to log passwords in clear text. You can even create a general rule like "Everytime you decided to weaken security for debugging purposes you should create a test that confirms this code will not be included in the release build".
No.
There should be no tests. There should be a rule that disables all debugging output in production builds. And, of course, all debugging output should use the mechanism that disables output with aforementioned rule.
Once that is implemented, testing is absolutely irrelevant, unless you are trying to test gcc.
Testing is for finding out if you have screwed up. Quality comes not from testing but from not screwing up.
Re: (Score:2)
All classes of tests are extremely limited in their usefulness. Some are just peddled better.
Re: (Score:2)
What if the next bug leaks pasword backwards? In BASE64? Only on Mondays?
You can't test quality into the system. Tests can merely show that something is terribly, terribly wrong, and likely you have deeper problems.
Re: (Score:2)
The next bug is the next bug. We are not talking about a bug here, at least not a direct bug. In this case somebody did something on purpose, which was to help during development but is definitely not ok in production.
It was one of millions things that happen in development. There is no way to count them all -- if developers had to record every instance of enabling or disabling various kinds of output, they would never have time for actual development.
This particular problem would not happen if there was a predefined way of producing debugging output, that is guaranteed to be never enabled in production builds. That would work even if no one ever tested anything. Because it's a matter of development infrastructure, not t
Re: (Score:2)
Could it be? Sure.
Could those tests also easily (and fairly trivially) be worked around by a developer just "trying to figure out what's happening" and accidentally checking in some bad code to a release branch? Sure.
It's very likely that Apple does builds where "CCFLAGS += -g -D__DEBUG__" doesn't get appended on the compile line. It's very likely that the developer who did this was trying to figure something out, got sloppy/rushed, and checked in something that hard-coded this behavior into the code, an
Re: (Score:2)
And if there is no debug flag? Just some print statements, or #ifdef's being removed, or something like that?
There's no way to guarantee that this problem will ever be caught via an automated test. You can (and should) certainly test for specific scenarios that you can think of, but there's no way automated testing can know the intent or possible ripple effects of changes the developer has checked in; "verify no debug information is included in the production binary" can be automated. "Make sure the dev
Re: (Score:2, Offtopic)
I might suggest that your endorsement might have given several people a reasonably compelling reason not to use it.
If you sincerely are advocating that product, you may want to consider altering your sales pitch so that you don't sound so much like a snake-oil sales vendor. Otherwise, you just sound like a raving lunatic.
Of course... if that was your intent. Carry on. Expect to be downmodded, however.
Re: (Score:2)
Off topic, almost certainly. Idiotic, without a doubt.... but not actually inappropriate or offensive unless a person is offended by people who sound nuts.
Re: (Score:2)
us mods can only hide it from people who don't read @ -1 ! :( But i have been reporting these as i see it to admins hoping for a nice IP ban.