Re: How do I see encrypted passwords?
Igor Bukanov wrote: > But what about simply asking for the master password each time the > dialog is shown? WORKSFORME. Edit->Preferences->Privacy & Security->Master Passwords->Master Password Timeout->Every time it is needed. Mike
Re: Risks using downled Mozilla builds
Thorsten wrote: > Is there any real reason, why almost the entire installation needs to be > done as root, just because someone wants a system wide install? > > What would one gain? Doing so only a small, comperably comprehendable > Script needs root privileges, greatly reducing a chance for a small bug > compromising the entire system. If you don't want to run the installer as root -- which may not be an unreasonable stance -- then use an RPM or some other similar package: they don't have anything to do with the installer, and are designed for system installs as root. Or, hop on over to mozdev and write a system installer, I guess. I'm not sure there's demand, but it's up to you. Mike
Re: P3P plans
Jonas Jørgensen wrote: > > Shouldn't you be fixing bugs instead of adding new features? > Shouldn't you be fixing bugs instead of being an ass on the newsgroups? (Heikki fixed 3 bugs and reviewed the fixes for more in the last week. How about you?) Heikki doesn't owe you anything, though if you're willing to cough up a salary, there are a handful of people out there who will let you direct their efforts. Interested? Mike
Re: Security Group Proposal, Draft 7
Mitchell Stoltz wrote: > My question is, is this a valid concern? If most of you think we should > use "[EMAIL PROTECTED]," then I'm fine with that, but I'd like to > hear opinions about this point. I don't think it's an issue, and if "security group proposal" is specific enough to have not attracted any questions about our crypto stuff, I think we'll be fine. (I don't know of any other organizations that suffer unduly under the weight of misdirected stuff to security@, other that spam that doesn't care about security of _any_ sort. But my sample size so far is pretty small.) > The second mailing list is for discussion among security group members. > Having a very specific name is not so impotant in this case, and short > is good, but if we're going to use [EMAIL PROTECTED] for the bug > reports address, we'll have to pick another for the group discussion > address. [EMAIL PROTECTED] for the Mozilla security group, I say. Mike
Re: Security Group Proposal, Draft 7
Brendan Eich wrote: > I must now channel jwz's ghost and object to lack of hyphens and > cybercrud "grp" in the last. If short wins, why not > [EMAIL PROTECTED]? Otherwise, -group it. [EMAIL PROTECTED] is the traditional notification address, I think. Mike
Re: Security Group Proposal, Draft 6
Mitchell Stoltz wrote: > Then we'll post a message > on a Known Vulnerabilities page, similar to what other open source > projects maintain. Then, any Mozilla vendor or distributor who wants to > inform their users about the existence of a bug can use the information > from the Mozilla page, but no more. *kiss* Mike
Re: New proposal for handling security bugs
Mitchell Stoltz wrote: > A determined cracker can find the exploit himself. The source code is > open, after all. We can't prevent that. What we can prevent is script > kiddies searching Bugzilla for ways to wreak havoc. That is our main > goal. Yes, they could subscribe to your mailing list, but fewer people > will think to look there than Mozilla, and the information they find on > your mailing list will not be sufficient to reproduce the bug. That's > two levels of protection. You can't be serious. "They won't think to look on your mailing list" is a level of protection? I think that giving a description of the vulnerability (of the user, not of the software -- "your Mozilla configuration data could be read by a hostile web-site operator" for something that exposed addressbook or prefs, for example) is a reasonable thing for an (indirect) provider of consumer software to do. Some might argue (I have) that it's the only responsible thing to do when we know that someone's data or privacy is at risk. I don't think _anyone_ is proposing that we publish exploit recipes widely and early, so debate about arming "script kiddies" seems less than germane. >> If I may issue vage warnings (but a bit more concrete than what Frank >> described) and workarounds at any time > > again, the criteria is "vague enough so that an attacker cannot > reproduce the exploit from your description." That's a great criterion, I think. Given that criterion, can we not post issues to a security.announce list as we find them, and/or mention significant security fixes in release notes? > There's a difference between 'publicly' and 'with your own customers.' I > believe this is a real difference. What happens for a group like Galeon, whose customers are everyone who downloads the software? Can they put a notice on their web site? At that point, we have people seeing that there's a Mozilla security defect on the Galeon web site, and wondering why mozilla.org didn't want to tell people. Speaking of bad PR... I'm having a hard time finding any significant open source project that doesn't talk about security bugs pretty much as soon as they're fixed, and instead relies on the downstream distributors and vendors to provide such notice. Apache, BIND, sendmail, XFree86 -- all of them seem to give public notice when there's a new release to cope with a security bug, if only with an appropriately-conspicuous entry in the release notes. So what I still don't get is why those examples[*] aren't suitable for us to follow. Can someone explain that to me? (I don't really like the "mozilla.org doesn't guarantee your safety, so it can't talk about it" argument, given that Netscape's own EULA disclaims any such warranty or guarantee, in big lawyerly letters.) [*] Examples of the kinds of notice that they give, demonstrating quite nicely the spectrum of provided detail: Apache: http://httpd.apache.org/info/security_bulletin_1.2.5.html BIND: http://www.isc.org/products/BIND/bind-security.html sendmail: http://www.sendmail.org/8.12.1.html XFree86: http://www.xfree86.org/security/ Mike
