Indeed, to be honest, I personally do not care much about customer expectations for FileZilla. It's not a commercial product, and there's no product manager who is responsible for making FileZilla like his / her (paying!) customers want it to be. I just find it awkward to talk about "customer expectations" for a small Open Source project like this one is (in terms of developers / lines of code, not users).
Sorry, I was ambigious (and sloppy in referring to customer - I typically try to refer to user when talking about OSS, but I do spend much more of my time consulting for commercial app security so it is habitual to talk about the customer rather than user). Let me clarify, what YOU expect of users is ludicrous, not what users expect of you. Considering that I have recommended filezilla to many a user just to get them off of windows explorer I know for a fact that at least some of your user base is not at all the type to use file system based encryption and you shouldn't operate under the mentality that it is reasonable to expect that is a common user scenario.
By saying "engineer around" you imply that the lack of password encryption is some sort of design flaw. I guess botg would argue it is not. It is a know limitation, and it's meant to be like this.
It is a design flaw. You might (but in no way have) argued that you considered this but felt other considerations warranted the plain text password, but that means you have accepted the risk of the flaw, not that the flaw is not present.
Common and well adopted? As Ryan already mentioned in his FD mail, even programs like Pidgin do not implement password encryption, and I doubt that the majority of OSS projects in the size of FileZilla (again, in terms of developers / lines of code, not users) do. Don't get me wrong, this should not be an excuse for not implementing encryption. I just doubt it's well adopted.
Yes, it is a problem endemic to smaller OSS projects, but speaking as a whole, most server apps protect passwords (even small OSS apps adhere to password hashing), and most large apps do as well. People would flip out if browsers still had such lax password standards for example, and FTP credentials are often just as important.
I hope you see that there's clearly a difference between a deliberate design decision and unwanted bugs like buffer overflows.
you haven't established that this was deliberate. There is no reason I should assume it exists for any reason other than people didn't think about the risk, anymore than people *still* don't think of the risk of unchecked buffer copies. My assumption is still that either no one thought of it, or no one gave a crap, not that someone was like "Hey, we should make this plain text instead of protecting it for the following deliberate reasons" though if you presented a rational justification I would certainly change my mind. That said, saying that if I fixed it myself it would be added to the repository underminds the deliberateness of this.
If you care so much about the user's security, why don't you submit a patch instead of just pointing fingers? Again, FileZilla basically is a one-man project. What concerns me, I'm grateful for what a cool FTP client I'm getting, for free. If it misses features I'd like to see added, giving back some lines of code is the least I can do. And once such a patch exists, I doubt it would be rejected due to some religious reasons.
Ah yes, the fix it yourself mentality that mars the entire open source community. When that is the habitual response it doesn't at all encourage people to give you any feedback.
To answer your question it is because it is a huge pain in the ass to grab source code, set up the appropriate build environment with all necessary dependencies, familiarize myself with the layout of functionality within the source (especially since, lets be honest, small open source projects rarely follow any stylistic guidelines that would make reading code easier, or even do trivial things like include comments. Your project might be better than most about that, and I am not accusing Filezilla specifically of that, but it is a common enough occurance that it is warrants default assumption status), make and test the change, and then sell whoever is the gatekeeper on the change. This flaw really wouldn't take someone invested and current in the project much time to fix and get adopted, but it is a pretty large time sync for someone not currently invested. If I was interested in continual involvement in the project it might be worth the effort, but I am committed quite enough to altruistic projects and really don't want to add another to that list.