138460 - support for loading of local and remote packages

Status: RESOLVED WONTFIX

(SeaMonkey :: Installer, enhancement)

Description

[rvj]

My understanding of xpinstall is that package address details (content, locale, 
etc) can be specified using the 'path' or 'url'

If path is, used then I understand that a package location can be created using 
relative or absolute file paths

a) content, install, path, /main/calculator/
b) content, install, path, c:///main/caclulator/

I presume that path should support the http protocol for read access?

c) content, sinstall, path, http://host/main/calculator/


For developers of application server packages, this would allow the loading 
(not installation)  of remote packages.

In other words, no code or data is installed locally only a pointer to the 
remote directories.

The xpinstall script would not attempt to install package content locally (it 
would certainly fail) but it would only create the appropriate chrome registry  
entries to allow read access of application server packages.


I do not see that this compromises the existing security architecture and 
provides a very simple common approach to 'loading' local and remote packages.

In otherwords the package based philosophy it maintained rather than creating 
arbitary xul files using a different security methods. 

I have tried to load a remote package using the http protocol but so far 
without success.

I am unsure if this is a a bug or an RFE. Certainly support for http would be 
very welcome for application server based developers.

Comment 1

[Kai Lahmann (is there, where MNG is)]

anybody konwing details about this?

Comment 2

[Grace Bush]

Jim,  would this be an enhancement?

Comment 3

[Jimmy Lee]

I am pretty sure this is an enhancement request versus a bug.  I know I have not
specifically tested this scenario.  Dan, do you have anything to add?  Thanks.

Comment 4

[K'Trina Medina]

Changing severity to enhancement

Comment 5

[Benjamin Smedberg]

Pike: aha, I found it! ;)

For the record, loading chrome from non-local sources was deemed a security
problem a while back, and was disabled. There has been talk of getting it
working again (mainly for https:, http: is probably too dangerous), but there
are issues with blocking loads of external chrome, and how the chromeservice and
cssloader deal with non-local content.

Comment 6

[rvj]

just out of interest is there any write up on what specifically is more 
dangerous about loading chrome across the net as opposed to locally

Ive never really understood why local installation of chrome is thought to be 
significantly safer.

The point I am making is that an installer program that points to a specific 
remote location is effectively a local installation. It cannot point anywhere 
else. !

I understand that perhaps the download data stream could be intercepted just as 
rogue copies of installation discs are possible.

If this is still thought to be too dangerous, why not just support signed 
chrome JAR packages .?

Comment 7

[Axel Hecht]

Not sure if there's a writeup, but I guess that the most evil thing about this is
that you trust your own system's security on the security of another.
Signed packages do get priviledges, so that might be an option. Apart from the
technical stuff.
The most pressing one would prolly be the loading of external entities, required
for localisation. This requires some serious XML parser work to make that work
good for remote content, as the current implementation blocks the parser during
that load.

Comment 8

[rvj]

" Not sure if there's a writeup, but I guess that the most evil thing about
this is that you trust your own system's security on the security of another."

Surely if you decide to use the package installer to install a package
whether it was supplied on disc or downloaded online, havent you already have 
made the decision to trust the supplier of the package?

It should not really matter where some of the files are physically located. 
(except for spoofing considerations)

For example new application skins specifically for the calculator package
can be made available without having to reinstall the entire package locally.

Comment 9

[Axel Hecht]

If you install a package locally from a server, you trust that the package and the
server are undamaged at the point of installation, if you install a package from
a server running from that server, you trust on that server being undamaged for
a rather long time in the future.
That's a significant difference, IMHO.
One way to deal with this would be to have checksums of the remote files locally,
and request approval of changes by the user. Not sure if the architecture allows
for this. (This should deal OK with locales and skins, switching skin shouldn't
cause you to revalidate each file.)

Comment 10

[Daniel Veditz [:dveditz]]

The xpinstall script engine has been removed from the trunk, bugs in it are obsolete.