Mozilla needs to be AutoUpdateable.

Need to create a better component than Browser-General for this.

Need requirements for this functionality.

Is this a gui thing or a guiless thing? assuming guiless and sending to xpapps. Hoping my assumption is wrong. please provide a spec or start a newsthread in n.p.m.<something> otherwise this bug is rather unusual and doesn't belong here.

Dup of bug 51998?

adding an initial patch for "AutoUpdate" functionality; --- features : 1) has the functionality of downloading .xpi's and installing them; 2) it is a separate DLL (can be merged with xpinstall, instead of a separate DLL) --- New files : 1) nsAutoUpdateTrigger.cpp, nsAutoUpdateTrigger.h 2) nsSoftwareUpdate.cpp, nsSoftwareUpdate.h (modified to register 'AutoUpdate') 3) makefile.win, generates 'autoupdate' lib & dll. other files are from 'xpinstall/src';

cc'ing dveditz for comments;

We're headed down the wrong path here. First, the "patch" appears to be a complete copy of xpinstall, so it's impossible to tell what you changed. Second, the test case shows that you added the new autoupdate object to the browser DOM context, which is a **HUGE** security hole were we to implement this as-is. **HUGE** It cannot be overstated: this would be the holy grail of security holes, no need for hackers to exploit tricky buffer overruns to get software to run on the victim's machine. Obviously the whole point of an install capability is to put software on someone else's machine, but it is such a dangerous capability that we must be extremely vigilant in making sure it can only be done in safe and controlled ways. "AutoConfig" is another dangerous capability -- allowing some remote site to control my prefs. Assuming we do proper security reviews on that and ensure that's limited to controlled enterprise installations then it would be safe to allow this "auto update" capability to happen in *that* already-secure context. This will require hooks in the autoconfig context (who is doing that?) that can talk to hooks in xpinstall, probably requiring some changes in both.

http://bugzilla.mozilla.org/show_bug.cgi?id=70348 is the bug for AutoConfig, being worked on by Mitesh Shah. Thanks Dan for addressing some of the security concerns!

Just so we're clear on this, the patch above cannot be checked in. We can't make UI-less auto-update functionality available to untrusted web scripts.

reassigning to jpm (please find a new owner)

This is not going to make emojo. Removing nsenterprise+.

Autoupdate also needs to be writtern in JS like getLDAPAttributes() , see bug 75955. Working on separating a JS context from Prefs so we can add this enterprise related functionality to it (bug 89137)

*** Bug 101067 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 23117 ***

Not a duplicate. bug 23117 is about checking for updates and notifying the user when one is available (standard end-user stuff), this one is about enabling site admins to remotely upgrade machines they're responsible for. I've taken the liberty of updating the summary since this isn't the first time people have tried to dupe the two.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

mitesh is no longer with us. reassigning to default module owner. bug 113387 tracks the original list of mitesh bugs

-> default assignee

severity->enhancement,cc sgehani, tpringle for input.

This feature existed in the 4.x world and involves the prefs backend and install world more than the XPApps world, IMHO.

ccing gregg landskov.

Any chance to get this done in Buffy scope?

``Single Points of Internet 0wnership'' paper by Nicholas Weaver http://www.cs.berkeley.edu/~nweaver/0wn2.html explains why auto-updating is such a huge security risk. Is there any way to have both auto-updating and also adequate security ? Off the top of my head, say Mozilla only auto-updated from a https: server on the local class-C network. Having to manually do something at one server for every class-C network is much less work for the site admin than manually doing something at every machine. Is the security risk in that case acceptable ? Is there a security keyword ?

The way to do it would presumably be to have the updates be cryptographically signed, and the administrator can decide which certificates are authorized to update.

Any chance of seeing this kind of functionality finished off and added to the nightly builds for testing?

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420