(Reposted, because I fell into spam-trap)
(Already posted in policy thread, but I received no response.)
Brendan Eich wrote:
We do need an automated update system.
As it happens, I wrote just such a system for Mozilla (for a customer,
but under the MPL). Half the code bases on my roaming module.
Daniel Veditz wrote:
site level filtering ... we're still arguing
Where?
___
Mozilla-security mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-security
Daniel Veditz wrote:
Figuring out an appropriate UI and security model is tough. When sites
offered .exe downloads we used to force people to explicitly save them and
launch them using the OS. This was to discourage stu^H^H^Hinexperienced
people from running any malware they ran across, with a
Daniel Veditz wrote:
Let's forget about the AOL-burdened past. I--and the Mozilla Foundation, I'm sure--want us to do the right thing now.
Yes, I hoped so. That's exactly the reason why I posted this.
Can we start over and give the existing policy (as written, not as executed) a try for a
I forgot:
There are currently 36 fixed, hidden bugs. Some of them fixed a
year ago.
A
query for the formerly hidden, now disclosed bugs
Ben Bucksch wrote:
* The known, hidden security bugs are usually *not* being fixed
timely (contrary to assertions by Mitch during the policy
discussion IIRC). Some critical ones rotted for years until they
were driven out. There are currently 59 hidden, unfixed bugs
GhostMouse wrote:
Whenn I try to do this in Mozilla 1.4, I have an option I've never seen
before, and that is the option to check a box that says send *THIS* email address as
anonymous FTP password (emphasis added) and then there is a place to actually write in
something, presumably an email
rvj wrote:
I am concerned with tampering at the local workstation
Then protect it at that level - prevent people from messing with it. It
doesn't make much sense to lock one door, if you leave the other door open.
If you still want to do that, write a little md5 checker and use that as
Nelson B. Bolyard wrote:
Decisions about whether a file is safe for some purpose should be made
based on the MIME content type, not the file name or extension.
Tell that MS Windows :-(.
Ben
Zade wrote:
How can you block/change the O/S identity as seen by the website you
visit, without disabling javascript?
Set your UA string (search on google for it). IIRC, that's the only
place where websites can see it. To check, visit http://gemal.dk.
Ben
.general removed per the charter.
is fixed
(which can take months, given current experiences, just check the old,
disclosed bugs).
The major roadblock is to agree that this procedure is wanted. Sorry for
bringing that up again, but it seems like current policy and its
implementation does not work.
Ben Bucksch
Beonex
Boris Zbarsky wrote:
I was just reading the nice article at
http://www.theregister.co.uk/content/55/27934.html and was struck by
the External Links section I have to wonder: Why exactly are we
not updating the known vulnerabilities page?
Actually, comparing the pages, most of them *are*
Dan Veditz wrote:
The Register article was from last May, when only one item was listed on the
page.
Nope.
Article says:
Mozilla riddled with security holes
By John Leyden mailto:john.leyden;theregister.co.uk
Posted: 05/11/2002 at 10:38 GMT
Frontpage says:
*Mozilla riddled with security
Chris LeBlanc wrote:
I would send something like this on to the people at StuffIt and Apple
Quicktime team.
To my knowledge, they have been notified by the bug finders from the
beginning.
not guarding
against that.
Most of that behaviour is adjustable by the user, in any of the
applications. Please so that. We recommend to disable the autostart
feature in Quicktime.
Ben Bucksch
Lincoln Yeoh wrote:
I have tried the www-html list,
And have read your proposal there (about a year ago?). (But I don't
remember the discussion exactly anymore.)
and other places, nothing happened
Maybe because there were valid concerns, maybe it's even just a bad
idea? To be taken
something in the HTML standard, you need a
make a decent case.
Ben Bucksch
Beonex
hocus, I think such measures are an extremely bad idea. On the internet,
you cannot trust that
* a certain host is the one you think it is (esp. so with HTTP and
in some cases even with HTTPS)
* that the data you receive is unaltered (with HTTP)
Giving any http host on the
/~piro/xul/_policymanager.html
I bcced who seems to be the author.
Ben Bucksch
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-get-non-queries.html
lists some problems to consider.
Mitchell Stoltz wrote:
Those long query strings can serve both purposes - security and
customization. They do roughly the same thing as cookies, although
each has
Frank Hecker wrote:
Christian Biesinger wrote:
What about posting information about this vulnerability at this page:
http://www.mozilla.org/projects/security/known-vulnerabilities.html
I've asked Mitch Stoltz (who maintains that page) to add an
appropriate entry.
While you're at it,
weaknesses, if you try to
protect yourself from powerful organisations like the U.S. government,
but that's surely no concern for credit cards (all your financial data
belong to them anyways :-( ).
Ben Bucksch
Leee wrote:
I can't find a SignTool 1.3 for Windows 2000 from
http://developer.netscape.com/software/signedobj/jarpack.html.
eh, try the NT4 one?
Christian Biesinger wrote:
Ben Bucksch wrote:
I wouldn't use the net installer at all and instead use the
tarballs/zipfiles or the full installer.
Well, that's useless - anybody who can manipulate the files that the
installer downloads can manipulate the installer itself as well so
Thorsten wrote:
Wouldn't it be possible to modify the installer to be able to Download
the Files being a normal user
Is there any real reason, why almost the entire installation needs to
be done as root, just because someone wants a system wide install?
I agree that downloading should
to display instead of execute the JS.
Apart from that, it is the wrong thing to do. The script is executed on
the user's machine, so I believe the user has a right to see whst is
being executed. Esp. because websites usually are not (and can not be)
trusted by the visitor.
Ben Bucksch
Matt Sheffield wrote:
I want to be able to use images on the WWW but never want to have them
in my e-mail (Web bugs). There should be a setting which allows the
user to control whether or not external image references are loaded.
This would enhance privacy and help reduce spammers'
[EMAIL PROTECTED] wrote:
Anyone know why this connection is made from my PC to the host :
h-204-29-187-156.netscape.com on port 119 whenever mozilla is running?
119 is news (usenet), the host is news.mozilla.org. Mozilla checks for
new news postings!
Please use a valid From or risk to be
Mitchell Stoltz wrote:
I think security is ambiguous, and doesn't precisely describe the
purpose of the address, which means it may attract more off-topic
posts. People may think it's for discussion of cryptography
engineering or physical building security or the security of Mozilla
Mitchell Stoltz wrote:
What about the other list address, [EMAIL PROTECTED]?
OK with me, but I don't care much.
Seriously, a .announce style mailing list is a good idea.
Sounds fine to me, although I think the authoritative list should be a
webpage. We can do a mailing list too.
No, my
Mitchell Stoltz wrote
! pThe Mozilla security bug group will have a private mailing list,
! [EMAIL PROTECTED],
Good.
to which everyone in the security bug group will be subscribed. This
! list will act as a forum for discussing group policy
! and the addition of new members, as described
Jesse Ruderman wrote:
How about having a sublist to which users can send reports of new security
bugs, so not all members of the list have to recieve all the spam?
.../discussion.
Agreed. [EMAIL PROTECTED] should be reserved for new reports, not
used for long discussion.
Reporters are
Mitchell Stoltz wrote:
As module owner, I'd be happy to maintain that page, along with
whoever we pick as peers. As with the rest of this proposal, I expect
that the amount of information disclosed on the public page will be
decided by consensus among the security group on a per-bug
Christopher Blizzard wrote:
What this policy does is set up a framework for end user distributors
and other interested parties to share information about security
vulnerabilities
You seem to assume that reports come from inside, from parties (esp.
companies) developing Mozilla. While that
Stuart Ballard wrote:
I don't know whether this will affect your views, but did you notice
that under this policy, the small, hand-picked group of people would
almost certainly include yourself?
Yes, I am aware of that. Actually, Mitch said something like that I
would certainly be part of such
Frank,
I repect you, but I strongly disagree with you here and with the
proposal. I believe that it is completely inadequate for an open-source
project.
Frank Hecker wrote:
What, if that bug or strongly related topics are discussed on the
mailing list? IMO, there should be a policy that
Stuart Ballard wrote:
So would you [...] allow bugs to be kept secret
indefinitely if a fix is provided?
No. No bug should ever be kept confidental infinitely. All bugs should
be, in any case, opened after about 6 months. That's another defect in
the current proposal IMO.
Information about
Mitchell Stoltz wrote:
[citation from draft proposal]
Ben Bucksch wrote:
Just that this point says fixed, while I want to inform in both
cases - when a bug gets discovered (and I have a workaround) and when
I have a fix.
That's what I intended. Sorry for the confusion.
That's very good
Nils Ellmenreich wrote:
I was talking about the referrer header string. If you remove it,
there are indeed pages that block you (IIRC, e.g. Cartoon pages from
the Washington Post)
Oh, I got confused.
What other major sites block you, if you don't send a referrer? (I
worry, because Beonex
Nils Ellmenreich wrote:
That's not quite a solution, because you'd have to quit Mozilla to
change it.
That's just a matter of an interface. The pref do supports switching at
runtime, I think. You mioght be able to set it in the JS console - never
tried it. Otherwise, there's a bug about a
Stuart Ballard wrote:
The only surefire way seems to be to disable onmouseover and onmouseout,
Right, and onmousemove.
which we can already do.
Really? How? As I see it,
http://www.mozilla.org/projects/security/components/configPolicy.html
describes only, how to disable JavaScript
Nils Ellmenreich wrote:
- banner ad (site) blocking based on regexps (that's more powerful
than the current block images from this server). Like junkbuster,
I'd like to have regexps on entire URLs
Yup. With one short and simple regexp, you can strip out 80+% of the
ads. (Squid supports
MIT is exploring, what I was scared about with JavaScript and XMLExtras:
Tracking not only links, but also mouse movements of website visitors.
Appearently, they are recorded via a JavaScript (onmousemove), sending
it back to the server and analysing it there.
They had a 65+% hit rate at
Mitchell Stoltz wrote:
Besides, maybe there's something that gets popped up on load or unload
that you do want to see. I doubt it. I'll build in the ability to
create an exception list for those cases should one arise.
FWIW, IIRC, there are some poorly written sites which desperately want
Jason Bassford wrote:
You can limit the lifetime of cookies. (The prefs are not yet listed in
all.js.) See bug 53354.
The only possibility I can see there are from your source code for
a possible fix that was then rejected by morse.
+user_pref(network.cookie.lifetimeLimit,0)
But if
Mitchell Stoltz wrote:
* Accept all other cookies but discard after two hours (or failing
that,
at the end of the session)
Not currently possible.
You can limit the lifetime of cookies. (The prefs are not yet listed in
all.js.) See bug 53354.
Jason Bassford wrote:
user_pref(capability.policy.default.window.open, noAccess);
user_pref(capability.policy.non_spammers.sites, http://www.microsoft.com;);
user_pref(capability.policy.non_spammers.window.open, allAccess);
user_pref(capability.policy.non_spammers.windowinternal.open,
Jason Bassford wrote:
http://bugzilla.mozilla.org/show_bug.cgi?id=75915
The short answer is that, no, this is not possible at present.
(Although it's being worked on.)
There are workarounds, I'll add them to the bug.
Gervase Markham wrote:
If the site requires users to use certificates to authenticate to the
server, the standard for that is TLS/SSL. Mozilla supports the client
certificate feature of the IETF standard Transport Layer Security
protocol, RFC 2246 section 7.4.6. Netscape Communicator
Jeffrey W. Baker wrote:
Can anyone spill the beans on port blacklisting
The code, for those interested:
Doug Turner wrote:
The basic deal is that some protocols should not be allowed to run on
some ports. Without any checking someone could do all sorts of evil
things
What do you mean with run? Mozilla shouldn't accept any connections
from outside. So, the ports can only refer to the
hm, that was a bit many typos, even for me :-(. Corrections and
additions below.
Ben Bucksch wrote:
If you have one, you can test it at SSL test sites.
http://www.mozilla.org/quality/security/smoketest.html
The web site is apparently being built by Microsoft UK [...]
If it really
Martijn Kluijtmans wrote:
I just vote for it.
Think of the following situation:
In a family, every member wants to use Mozilla's, mail facilities
- Father gets confidential information from clients
- Daughter gets love letters by her friend
- Mother
enz.
Yes, we had this discussion
Peter Lairo wrote:
User Profiles should be able to be protected with passwords.
If you agree with the above statement, please vote for this BUG to be
fixed here:
http://bugzilla.mozilla.org/show_bug.cgi?id=16489
Where do I vote for this bug getting WONTFIX? :-)
Henri Sivonen wrote:
It seems to me that the accessed URLs are revealed to Alexa, if the
What's Related panel is in the sidebar even if it isn't the active
panel. However, if I remove the panel from the sidebar, sending URLs
appear to stop. Is this a correct diagnosis?
Might be. There
PSM questions to .crypto, please...
Eric Murphy wrote:
I would like to store data in the PSM from JavaScript for a login interface.
This is for the Jabberzilla client, and is simply username, password, etc...
Right now I am storing the data in cookies, and that is not cool. Is there a
way I
I had a nice idea how to quickly distribute information about / fixes
for security bugs to all active users.
You can just add a (default) bookmark with an update schedule, sat to
1440 minutes (1 day). That way, each day the browser runs, it will query
a certain page on the distributor's
Alan Zhu wrote:
under M18 debug version of mozilla.exe.
please use 0.7.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Bucksch wrote:
A serious security problem in Macromedia's Shockwave Flash plugin for
all platforms and browsers has been published on BugTraq. Exploited,
it allows an attacker to run arbitary code on your machine.
After the problem has
Heiko Becker wrote:
what is, when I use the Quicktime Plugin for play
Flashanimations???
I don't know.
If the Quicktime plugin uses the Flash plugin again, then you are
vulnerable. If Quicktime has its own Flash interpreter, it might or
might not be vulnerable.
es not come with Flash plugins, but might have
imported those of Netscape Communicator 4.x or you might have installed one
yourself.
Ben Bucksch
Beonex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Signed by [EMAIL PROTECTED]
iD8DBQE6VAAkRY0V+h7BIpkRAp5fAJ4k+bDaU5gApac6YRF
Peter Lairo wrote:
Ben Bucksch wrote:
I think, many of those "brothers" are able to get beyond such a simple
"security" protection.
You're wrong. You obviously have little contact with "regular" people.
Got me. I was born that smart, so I never went to sch
Mitchell Stoltz wrote:
Making people aware that vulnerabilities exist and how to protect
themselves is a good thing. However, I won't be able to participate
in such a newsgroup, and if Mozilla security problems are going to
be disclosed rapidly, this will seriously limit my and
Ben Bucksch wrote:
Ideally, a release engineer would also create an approriate fix
distribution, e.g. an XPI file containing the fixed library only.
However, this must not hold back the post by more than a few hours.
This is only, if mozilla.org still wants to release binary Milestones
Frank Hecker wrote:
But again, we are talking about people being cut off
from information only for a limited period of time.
But this period is important. Distribution of fixes takes 1 or 2 days
*at least*. Within that timeframe, crackers would know about the
vulnerability and users of
65 matches
Mail list logo
