Hello, I know have some details about the bug, but I don't know, if it could be fixed with these information.
First I want to answer some replies: > As you said: The passphrase entry window is for signing and should(!) be > independent from encrypting the mail. Yes, I'm aware of that, but I don't know, what you want to tell. > But if the bug *doesn’t* exist, then won’t you have gotten angry over > nothing, and don’t you deserve better than that? No, because my email includes a general opinion on Enigmail, because there are also other things, which could make me angry. > Enigmail is in a very interesting position, and one that’s shared by a lot of > open-source software projects: a lot of people rely on it but astonishingly > few are willing to contribute in a meaningful way. Yeah, it's not a good situation to establish high quality and secure software. > Two members of the Enigmail team are “contaminated” by US government > associations. John Moore used to work at Fort Meade when he was with the > United States Marine Corps, and my father’s a United States federal judge. > If either of us ever touched the codebase, many people would consider > Enigmail to be “tainted” by our work. So right there, of the already-small > group, two of us can’t do any development work. Other people have their own > limitations: some of us aren’t coders, for instance. I don't think this is very well reasoned or rational. People have not much control over the developers of the software they use. They rely on packages in their distributions, which may be developed or maintained by "contaminated" associations. Tor is massively founded by US government associations. SELinux is developed by the NSA, and still people (and I bet also paranoid experts) are using it. What code is contaminated more? Which has a higher security risk? A code, which has much lines of codes, is not well documented, not well funded and has not much developers or a code, which is "contaminated" by contributions from untrustworthy (but probably competent) persons, who can improve their trustworthiness, if they decrease the code size, trying to refactor the code to a clean and documented code? I'm convinced it's harder to implement backdoors and vulnerabilities in code, if it has less lines, is clean and well-documented. I think the difference of a clean code with purposely inserted bugs and a bad code because of a lack of a resources is, that the clean code contains in the best case only few purposely inserted bugs (which have to be hidden very well), and the bad code contains every bug, which could be made, if you don't have the resources to write good code. > The problem is that there are so few developers, Why that's the case? I just looked at the code for some minutes, and I wanted to know, what happens before sending an email, and what happens after sending an encrypted and signed email. I didn't spend much time, but not chance for me. I'm not a code reviewer. I wouldn't know, where to begin, to study Enigmail. There is a handbook for users, but as far as I see, nothing for potential developers. -- > Explain the bug and give us all details we have to know > to fix this bug. I'm afraid, that there is not enough information to fix this bug. First I thought, it was just the canceling of the password entry to sign the email. I asked the journalist, what happened in this situation and he said, a window popped up. It was probably the window, if Enigmail is something like in a endless loop or something, where you have to choose to stop the script or to continue. I assume, we stopped the script. Yes it is dumb to think Enigmail is working correctly, if you "stopped the script". What would be the solution? Clicking continue? I don't, if we were still in an endless loop or something like that. The problem is, that this window popped up. There are sometimes situation, where this window is popping up, and you don't know why. There is a secure programming practice, which says, that you have to fail-safe. So it shouldn't be actually possible to write an email, if Enigmail aborted unexpectedly. Version details: - Enigmail Version 1.7.2 - Windows 7 Home Premium, Service Pack 1 - Thunderbird 31.3.0 > What is worse: > - People making mistakes that might bring people into prison > - People knowing about mistakes and being just too lazy > to file bug reports to avoid bringing people into prison > ? I understand, that you want me to make believe, I could be responsible, if someone have to go to jail, because of an Enigmail bug, because you are actually deeply involved in the Enigmail project, which have to deal with code, which is probably not reaching a state-of-the-art usability and security standard for code/programs. What is worse: - Hoping that there is no bug in some thousands lines of code, which is not documented and only understood by two persons (two?!), hoping there are people to file bug reports to a project, which decided in the past to prefer usability over security (all keys valid by default). Not telling the users that the security of the project is based rather on hope instead of clean, well-documented code. - Trying to get in a state, with a documentation for developers, with a clean, well-documented code, which makes it possible to get more security, developers, instead hoping to get bug reports for a code, where we have to control of "The bring people into prison"-argument is not reasoned. Enigmail _STILL_ doesn't warn people, if they use unchecked public keys. Just tested it. It's kinda the same like in the past. Maybe people get into prison, because it's convenient. And if a security software, wants make everything convenient instead of secure, this could be a deeper problem instead of one single bug of many. Don't understand me wrong. I think it's cool, that we have something like Enigmail. But in the long-term view, there huge issues to be solved, if we want to have a software, where we have a peace of mind, when using it. Best regards, Kristy _______________________________________________ enigmail-users mailing list [email protected] To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
