I have an idea the.deb package recommends "packagekit". If that conflicts with "python3-aptdaemon.pkcompat", I guess your package manager might offer to remove it. You could try using --no-install-recommends.
If you try to install a program that needs a library that is only available through your distribution, then 0install will offer to install it using PackageKit, if PackageKit is available.
In order for it to work, the software developer has to not only publish their software on the Zero Install system, they have to publish their software for ALL the distros on it. But, we all know well that most software developers regard this as far too cumbersome an undertaking and will instead publish only a single or couple of binaries.
Of course, that's not an issue for programs written in Python, Ruby, Java, etc.
For C, you can also publish a source version and let the users compile (with 0install handling the build dependencies). Also, if someone wants to set up a build farm for a particular platform, they can use these source packages to create binaries automatically (e.g. for PPC binaries).
Producing separate binaries for different distributions (e.g. Ubuntu and Fedora) isn't necessary; one binary should work everywhere. The exception would be if the distributions compiled the libraries with incompatible options, but that doesn't tend to happen these days. If it does, specify the dependency as distribuion="0install" to force the use of a 0install version rather than the distribution package.
- It's designed for browser support, which is necessary to prevent phishing attacks and improve ease of use. It's hard for your browser to log in to OpenID sites (e.g. the Firefox OpenID plugin(s) fail on several sites which use fancy login UIs).
Auto-login is always problematic in security terms, even if it is exceptionally convenient.
I don't think anyone is suggesting auto-login (the browser logs the user in without action from the user). The issue is whether the browser can provide a login button in the chrome which, when clicked, allows the browser to handle the rest of the process securely (e.g. not displaying any random phishing site that the web-page tries to send you to). If you need to authenticate, the browser needs to ask for the password in a way that clearly shows it's OK to enter it (e.g. in a clearly-marked popup).
I think the main differences are that it uses email addresses instead of an URL (which people don't "get" as being your identity token)
Once it's ready (supporting primary IdP's), the ID doesn't need to be an email address (just an ID with an email-like structure).
and it doesn't give the authorities full power to access your accounts (since the private key for authentication is stored on the browser).
I don't think so. That key is only accepted because it's signed by your IdP, which can just as easily sign another one if the authorities request it.
The main advantages I see are:
- Verifying a login doesn't tell you're IdP who signed in to the site. The site only requests the IdP certificate, not your personal one.
- It's designed for browser support, which is necessary to prevent phishing attacks and improve ease of use. It's hard for your browser to log in to OpenID sites (e.g. the Firefox OpenID plugin(s) fail on several sites which use fancy login UIs).
- Putting more of the logic in the browser simplifies the protocol (although they seem to be adding extra complexities quite fast).
I watched the video, but I still don't understand how convergence is better than putting the certificates in DNS with DNSSEC. He says that DNS registrars are not reliable enough, but from the video it looks like convergence ultimately relies on them anyway. e.g.
If I control the DNS entry for paypal.com then I just change its IP address to point at my server. People using convergence will find my server in DNS, get its (self-signed) certificate and send it to the notaries. The notaries will see that it is different from their cached copy, which will trigger them to check for updates. They'll all go to the (compromised) DNS system, get the new IP address, get the fake certificate and return "OK" to the user. What am I missing?
Likewise with the new libpng, and bdb. Other programs will start using the newer versions, but your program will stay with the version that works. You can then work on fixing the bugs and getting a new release out in your own time, without having to rush.
For example, I distribute a lot of Python programs using 0install. They all started "#!/usr/bin/env python". When ArchLinux decided that "python" would now be Python 3, they all broke. But by adding a few lines to my 0install feed, I got them working again:
... And if one wants, it can even rely on LSB I believe, eliminating a lot of the need to include copies of base libraries, and a decent starting point (though I can't tell if 0Install allows that, I think ROX application directories do, and this looks like a way to replace them though.
I'm not quite sure what you're asking here, but to be clear:
0install always shares libraries and other dependencies. For example, if your program depends on Java then 0install will use the distribution's version of Java (if installed), or 0install may download a 0install package of Java, or it may get Java from your distribution (using PackageKit). A 0install package should never need to bundle libraries.
On a multi-user system you can enable system-wide sharing. This is off by default because it requires adding a new sudo rule, and adding one automatically would be rude (the admin should be in charge of the sudoers file).
0install does not touch any files outside of ~/.config/0install.net/ and ~/.cache/0install.net/ by default, and it won't let packages change things at install time either. This is necessary so that it can be used with sandboxes.
The only exceptions are that it will make a configuration change that you request explicitly. For example, if you ask it to add Firefox 4 to your Network menu then it will do that, or if you ask it to add a "firefox4" shell command to run it then it will create a "firefox4" script in your $PATH.
You might be interested in the EBox sandboxing demo (the challenge is to create a package that accesses a user's files without the user's permission).
RISC OS application directories and Apple bundles have the nice property that you can install from anywhere, can have multiple versions and there are no conflicts between packages (e.g. both installing a "/usr/bin/convert"). But shared libraries are a pain because you have to install them manually, and upgrading a library needed to install program B can make program A stop working.
Debian packages have the nice property that you get dependency handling and automatic updates, and shared libraries work better. The system automatically installs a library version that works with A and B, if possible, or refuses to install B if there is no such version.
0install combines the best of both systems: you can get software from anywhere, have multiple versions at once and there are no conflicts. But you also get dependency handling, updates and shared libraries. It automatically installs a library version that works with A and B, if possible, or installs two different versions of the library in parallel if not.
It's perhaps more like Java Web Start in concept, but it works with any language (including Java). There is the 0export tool to create self-extracting bundles, but yes in the normal case it assumes that 0install will already be on the machine.
What's that? It doesn't run on any of those? Oh dear.
Yes, some platforms are so locked down that they won't let you run 0install. But it has been ported to all the common platforms that allow it (Linux, Unix, Mac OS X, Windows).
Python source is generally compatible (go another level deeper and you'll find that the.py files are mostly symlinks to a single copy, at least on Debian-type systems).
However, the compiled.pyc files need to be regenerated for each version, which explains the separate directories. The symlinks are a messy hack, resulting from the fact that Python requires the.pyc files to go in the same directory as the corresponding.py files, even though you need multiple.pyc files for each.py file. If Python could cache the.pyc files somewhere else, the mess could go away.
The main problem with Python compatibility is with the C ABI, which varies across different packages, making it impractical to use Python to add scripting to a C program, for example:
What is needed is something like SELinux, which makes it impossible for applications to do things they shouldn't be doing.
For something like SELinux to be useful you need to be able to write a secure policy. If your installation system's installation model is "When a package is installed, it can write files to/usr/bin,/usr/lib and/etc" then writing a secure policy is basically impossible.
This is where something like Zero Install comes in. If you have a model* where installation is "safe" (Zero Install theoretically allows malicious users to install malicious packages system-wide, safely) then you only have to worry about writing policies for running things, which should be a lot simpler. e.g. the SELinux policy might say that the driver can read from the printer queue directory and write to the printer device.
Yes, "model". There may be implementation bugs too, but at least they can be fixed easily as they're found, assuming the underlying model is right.
The W3C believe that their efforts with XHTML are going unnoticed or unused by many websites out there.
I've noticed that MSIE tends to render (valid) XHTML by just displaying the raw XML. I'd imagine that that's quite a barrier to adoption.
Removing the DOCTYPE and avoiding CDATA sections seems to help, presumably because Explorer just assumes it's HTML in that case. But then it
doesn't validate, of course. Also, what extension should be used for local files (e.g. documentation) if Windows users must be able to double-click the
files to read them?
This is because the "Check for updates" in Firefox relies on a well-known security flaw in Windows, namely that every user is running as an administrator, and thus has the authority to modify system files. In Linux, since you are not browsing the web as root, it is perfectly understandable that you cannot update the systemwide installation of Firefox from the browser window.
It doesn't have to be that way. When you type 'firefox', you want your computer to run the software from http://www.mozilla.com/firefox. Setting this short-cut (associating this short name with the full URL) should indeed require admin access if it is to affect all users. But, if you let each user store this association themselves, so that typing 'firefox' expands to telling the computer "Run http://www.mozilla.com/firefox", there's no reason why the computer can't be smart enough to only download and store the actual program code once.
See 0install.net for an example of this way of running programs.
Repository based installation is NOT the way to go. Autopackage is just a pretty frontend around the same problem. Until we can install and remove applications as easily as OSX users can, we don't stand a chance.
You already can: 0install.net. More easily, in fact, because Linux will automatically fetch the dependencies and check for updates. Things have moved on since the days of centralised APT repositories where you have to be root just to install something.
From Zeroinstall: Anyone can install software You don't have to be root just to install a word-processor.
Eh, you can do this today. Just install an app in userspace. That's all.
You can do each of Zero Install's goals in other systems, but not all together.
Eg, Debian's APT shares downloads between users, but users can't install with it. Autopackage lets users install, but not share. Windows lets users share, but isn't secure. Etc...
Adobe Acrobat Reader starting supporting embedded Javascript with version 7.0, although you can disable it in the preferences dialog. Apparently it bugs you every time you start the program to re-enable it, though.
Actually, it bugs you when you try to quit, not when you load it up. Odd. The message says "This document contains JavaScripts. Do you want to enable JavaScripts from now on? The document may not behave correctly if they're disabled."
It says this even if you run acroread without loading any document at all!
If the key owner is a responsible software developer today, they're unlikely to turn into a script kiddie overnight.
That's not the point.
The problem is that that given the way 0install works... once you have agreed to accept a key, that key now has the ability to access your computer without any further explicit action.
No, it's only used when you upgrade. No incomming connections are allowed; everything is triggered by a local user. For the injector only, you can optionally get it to check for updates periodically. In that case, you have to click Execute to download the program after the update is fetched and you've confirmed you want the new version. If you don't like it, set the freshness to "no automatic updates". However, consider that automatic checks will also warn you if your current software has a security flaw, which is probably a win overall.
If the application is deleted to save space, it will automatically be redownloaded the next time you run it, right?
Yes, but again that's an explicit action on your part. For the injector, you'll have to click Execute in the case of re-downloading.
Right now if gimp.org is compromised, the only people who have to worry about that compromise are peolpe who explicitly downloaded and installed gimp. They know they did it.
Note that the interfaces would typically be GPG signed on a developer's machine. The web server shouldn't have the private key, so a mere server compomise doesn't let the attacker upgrade software without confirming a new key.
With 0install, anyone who clicked on gimp and went off to make a cup of coffee while this fairly large application was started may miss it reinstalling, because it never asked them if they wanted to reinstall it... because it trusted the gimp.org key.
The injector won't download software without you clicking on Execute, so it can't happen when you're away making a cup of tea. Traditional Zero Install (not using the injector) shares updates between users, but some local user still has to trigger the update.
Slashdot Mirror
I have an idea the .deb package recommends "packagekit". If that conflicts with "python3-aptdaemon.pkcompat", I guess your package manager might offer to remove it. You could try using --no-install-recommends.
If you try to install a program that needs a library that is only available through your distribution, then 0install will offer to install it using PackageKit, if PackageKit is available.
In order for it to work, the software developer has to not only publish their software on the Zero Install system, they have to publish their software for ALL the distros on it. But, we all know well that most software developers regard this as far too cumbersome an undertaking and will instead publish only a single or couple of binaries.
Of course, that's not an issue for programs written in Python, Ruby, Java, etc.
For C, you can also publish a source version and let the users compile (with 0install handling the build dependencies). Also, if someone wants to set up a build farm for a particular platform, they can use these source packages to create binaries automatically (e.g. for PPC binaries).
Producing separate binaries for different distributions (e.g. Ubuntu and Fedora) isn't necessary; one binary should work everywhere. The exception would be if the distributions compiled the libraries with incompatible options, but that doesn't tend to happen these days. If it does, specify the dependency as distribuion="0install" to force the use of a 0install version rather than the distribution package.
To get the hashes of the latest compatible versions, you could use 0install. e.g. to find the hashes for the dependencies of the SAM program:
/home/tal/work/serscis-access-modeller/serscis-access-modeller-any-any
/var/cache/0install.net/implementations/sha1new=daf7bfada93ec758baeef1c714f3239ce0a5a462
/var/cache/0install.net/implementations/sha1new=bb9479c20f7684b9423be7d76194929e9b6fb690
$ 0install select http://www.serscis.eu/0install/serscis-access-modeller
- URI: http://www.serscis.eu/0install/serscis-access-modeller
Version: 0.16-post
Path:
- URI: http://repo.roscidus.com/java/iris
Version: 0.6.0
Path:
- URI: http://repo.roscidus.com/java/swt
Version: 3.6.1
Path:
- URI: http://repo.roscidus.com/utils/graphviz
Version: 2.30.1-1
Path: (package:arch:graphviz:2.30.1-1:x86_64)
- URI: http://repo.roscidus.com/java/openjdk-jre
Version: 7.13-2.3.7-2
Path: (package:arch:jre7-openjdk:7.13-2.3.7-2:x86_64)
(so, on my system, graphviz and the JRE are provided by the system, while IRIS and SWT give the required hashes)
True, but if you use 0install then you can specify the version you want in the metadata, e.g.
... etc.
<command name='run' path='myprog.py'>
<runner interface='http://repo.roscidus.com/python/python'>
<version not-before='2.6' before='3'/>
</runner>
</command>
will select Python 2.6 or 2.7 on Debian, Ubuntu, Fedora, OpenSUSE, Arch, Windows, MacOS X,
(example taken from the docs at http://0install.net/local-feeds.html)
The Java equivalent of Capsicum is Joe-E: http://code.google.com/p/joe-e/
- It's designed for browser support, which is necessary to prevent phishing attacks and improve ease of use. It's hard for your browser to log in to OpenID sites (e.g. the Firefox OpenID plugin(s) fail on several sites which use fancy login UIs).
Auto-login is always problematic in security terms, even if it is exceptionally convenient.
I don't think anyone is suggesting auto-login (the browser logs the user in without action from the user). The issue is whether the browser can provide a login button in the chrome which, when clicked, allows the browser to handle the rest of the process securely (e.g. not displaying any random phishing site that the web-page tries to send you to). If you need to authenticate, the browser needs to ask for the password in a way that clearly shows it's OK to enter it (e.g. in a clearly-marked popup).
I think the main differences are that it uses email addresses instead of an URL (which people don't "get" as being your identity token)
Once it's ready (supporting primary IdP's), the ID doesn't need to be an email address (just an ID with an email-like structure).
and it doesn't give the authorities full power to access your accounts (since the private key for authentication is stored on the browser).
I don't think so. That key is only accepted because it's signed by your IdP, which can just as easily sign another one if the authorities request it. The main advantages I see are:
- Verifying a login doesn't tell you're IdP who signed in to the site. The site only requests the IdP certificate, not your personal one.
- It's designed for browser support, which is necessary to prevent phishing attacks and improve ease of use. It's hard for your browser to log in to OpenID sites (e.g. the Firefox OpenID plugin(s) fail on several sites which use fancy login UIs).
- Putting more of the logic in the browser simplifies the protocol (although they seem to be adding extra complexities quite fast).
I watched the video, but I still don't understand how convergence is better than putting the certificates in DNS with DNSSEC. He says that DNS registrars are not reliable enough, but from the video it looks like convergence ultimately relies on them anyway. e.g.
If I control the DNS entry for paypal.com then I just change its IP address to point at my server. People using convergence will find my server in DNS, get its (self-signed) certificate and send it to the notaries. The notaries will see that it is different from their cached copy, which will trigger them to check for updates. They'll all go to the (compromised) DNS system, get the new IP address, get the fake certificate and return "OK" to the user. What am I missing?
You raise an excellent set of points. So how does 0install fix this?
Firstly, you don't need to find packagers for each distribution. You create one XML file, which allows everyone to run the program.
When the new GCC comes out and breaks your program, you just change the version restriction in your XML:
<requires interface='.../gcc'>
<version before='4.6'/>
Likewise with the new libpng, and bdb. Other programs will start using the newer versions, but your program will stay with the version that works. You can then work on fixing the bugs and getting a new release out in your own time, without having to rush.
For example, I distribute a lot of Python programs using 0install. They all started "#!/usr/bin/env python". When ArchLinux decided that "python" would now be Python 3, they all broke. But by adding a few lines to my 0install feed, I got them working again:
<runner interface='http://repo.roscidus.com/python/python'>
<version before='3'/>
</runner>
... And if one wants, it can even rely on LSB I believe, eliminating a lot of the need to include copies of base libraries, and a decent starting point (though I can't tell if 0Install allows that, I think ROX application directories do, and this looks like a way to replace them though.
I'm not quite sure what you're asking here, but to be clear:
0install always shares libraries and other dependencies. For example, if your program depends on Java then 0install will use the distribution's version of Java (if installed), or 0install may download a 0install package of Java, or it may get Java from your distribution (using PackageKit). A 0install package should never need to bundle libraries.
On a multi-user system you can enable system-wide sharing. This is off by default because it requires adding a new sudo rule, and adding one automatically would be rude (the admin should be in charge of the sudoers file).
In the case of 0install, the command name (if any) is chosen by the user, not the package. So you might do something like this for shell use:
$ 0alias convert-img http://image-editor.org/convert
$ 0alias convert-text http://text-converter.com/convert
If a package depended on one of these, it would express that in its dependencies. e.g.
0install would ensure that example.com's convert command was in $PATH, but just for the program that needed it.
It's similar with libraries. A library's files are only in scope for programs that depend on that library.
0install does not touch any files outside of ~/.config/0install.net/ and ~/.cache/0install.net/ by default, and it won't let packages change things at install time either. This is necessary so that it can be used with sandboxes.
The only exceptions are that it will make a configuration change that you request explicitly. For example, if you ask it to add Firefox 4 to your Network menu then it will do that, or if you ask it to add a "firefox4" shell command to run it then it will create a "firefox4" script in your $PATH.
You might be interested in the EBox sandboxing demo (the challenge is to create a package that accesses a user's files without the user's permission).
RISC OS application directories and Apple bundles have the nice property that you can install from anywhere, can have multiple versions and there are no conflicts between packages (e.g. both installing a "/usr/bin/convert"). But shared libraries are a pain because you have to install them manually, and upgrading a library needed to install program B can make program A stop working.
Debian packages have the nice property that you get dependency handling and automatic updates, and shared libraries work better. The system automatically installs a library version that works with A and B, if possible, or refuses to install B if there is no such version.
0install combines the best of both systems: you can get software from anywhere, have multiple versions at once and there are no conflicts. But you also get dependency handling, updates and shared libraries. It automatically installs a library version that works with A and B, if possible, or installs two different versions of the library in parallel if not.
It's perhaps more like Java Web Start in concept, but it works with any language (including Java). There is the 0export tool to create self-extracting bundles, but yes in the normal case it assumes that 0install will already be on the machine.
What's that? It doesn't run on any of those? Oh dear.
Yes, some platforms are so locked down that they won't let you run 0install. But it has been ported to all the common platforms that allow it (Linux, Unix, Mac OS X, Windows).
http://0install.net/tests/Chromium.xml
Tested on Ubuntu/Jaunty so far, but let me know if it doesn't work on other distributions.
Python source is generally compatible (go another level deeper and you'll find that the .py files are mostly symlinks to a single copy, at least on Debian-type systems).
.pyc files need to be regenerated for each version, which explains the separate directories. The symlinks are a messy hack, resulting from the fact that Python requires the .pyc files to go in the same directory as the corresponding .py files, even though you need multiple .pyc files for each .py file. If Python could cache the .pyc files somewhere else, the mess could go away.
However, the compiled
The main problem with Python compatibility is with the C ABI, which varies across different packages, making it impractical to use Python to add scripting to a C program, for example:
http://www.mail-archive.com/python-3000@python.org/msg09051.html
For something like SELinux to be useful you need to be able to write a secure policy. If your installation system's installation model is "When a package is installed, it can write files to /usr/bin, /usr/lib and /etc" then writing a secure policy is basically impossible.
This is where something like Zero Install comes in. If you have a model* where installation is "safe" (Zero Install theoretically allows malicious users to install malicious packages system-wide, safely) then you only have to worry about writing policies for running things, which should be a lot simpler. e.g. the SELinux policy might say that the driver can read from the printer queue directory and write to the printer device.
Yes, "model". There may be implementation bugs too, but at least they can be fixed easily as they're found, assuming the underlying model is right.
I've noticed that MSIE tends to render (valid) XHTML by just displaying the raw XML. I'd imagine that that's quite a barrier to adoption. Removing the DOCTYPE and avoiding CDATA sections seems to help, presumably because Explorer just assumes it's HTML in that case. But then it doesn't validate, of course. Also, what extension should be used for local files (e.g. documentation) if Windows users must be able to double-click the files to read them?
http://0install.net/tests/Inkscape.xml
It uses the RPM, which works on Ubuntu/5.10 and Debian/testing if you have the appropriate libraries installed:
You don't need to be root to install this way. Make sure you tick 'Help test new versions', though, or you'll get the previous 0.43 version.
It doesn't have to be that way. When you type 'firefox', you want your computer to run the software from http://www.mozilla.com/firefox. Setting this short-cut (associating this short name with the full URL) should indeed require admin access if it is to affect all users. But, if you let each user store this association themselves, so that typing 'firefox' expands to telling the computer "Run http://www.mozilla.com/firefox", there's no reason why the computer can't be smart enough to only download and store the actual program code once.
See 0install.net for an example of this way of running programs.
You already can: 0install.net. More easily, in fact, because Linux will automatically fetch the dependencies and check for updates. Things have moved on since the days of centralised APT repositories where you have to be root just to install something.
Take a look at the screenshots!
Eh, you can do this today. Just install an app in userspace. That's all.
You can do each of Zero Install's goals in other systems, but not all together.
Eg, Debian's APT shares downloads between users, but users can't install with it. Autopackage lets users install, but not share. Windows lets users share, but isn't secure. Etc...
Actually, it bugs you when you try to quit, not when you load it up. Odd. The message says "This document contains JavaScripts. Do you want to enable JavaScripts from now on? The document may not behave correctly if they're disabled."
It says this even if you run acroread without loading any document at all!
That's not the point.
The problem is that that given the way 0install works... once you have agreed to accept a key, that key now has the ability to access your computer without any further explicit action.
No, it's only used when you upgrade. No incomming connections are allowed; everything is triggered by a local user. For the injector only, you can optionally get it to check for updates periodically. In that case, you have to click Execute to download the program after the update is fetched and you've confirmed you want the new version. If you don't like it, set the freshness to "no automatic updates". However, consider that automatic checks will also warn you if your current software has a security flaw, which is probably a win overall.
If the application is deleted to save space, it will automatically be redownloaded the next time you run it, right?
Yes, but again that's an explicit action on your part. For the injector, you'll have to click Execute in the case of re-downloading.
Right now if gimp.org is compromised, the only people who have to worry about that compromise are peolpe who explicitly downloaded and installed gimp. They know they did it.
Note that the interfaces would typically be GPG signed on a developer's machine. The web server shouldn't have the private key, so a mere server compomise doesn't let the attacker upgrade software without confirming a new key.
With 0install, anyone who clicked on gimp and went off to make a cup of coffee while this fairly large application was started may miss it reinstalling, because it never asked them if they wanted to reinstall it... because it trusted the gimp.org key.
The injector won't download software without you clicking on Execute, so it can't happen when you're away making a cup of tea. Traditional Zero Install (not using the injector) shares updates between users, but some local user still has to trigger the update.