2008/1/21, Thomas Leonard <firstname.lastname@example.org>:
> Ok. I did the rebuild a few times, and it does work fine... including the
> part where 0compile reinstall zero-install through zero-install ;-)
Probably it needed/wanted a newer version of 0launch than the default
one on your system, so the system 0launch downloaded a newer copy for
0compile, without disrupting the system version. Clever, eh?
Not bad, true. Unless they turn out to be incompatible :-(
Yes. If you email me the .bz2 files I'll upload them.
For the XML files, you need to sign them. This should do it:
$ 0alias 0publish http://0install.net/2006/interfaces/0publish
$ 0publish --xmlsign --local=GLib-dev-2.4.8.xml GLib-dev.xml \
Exported public key as '....gpg'
$ 0publish --xmlsign --local=ROX-Filer-2.7.xml ROX-Filer.xml \
This creates signed files called ROX-Filer.xml and GLib-dev.xml. Send
them to me too, along with the GPG public key it exported.
Perfect. It worked fine. Maybe some knowledge to be added to the roscidus wiki?
Well, the problem here is that the thumbnailers are "registering
themselves". To do it properly, they should be registered by some
other component, of the user's choosing. e.g. when you add ROX-Filer,
it's 0alias that creates the 'rox' script, not ROX-Filer. When you use
AddApp, AddApp creates the launcher, not the application you added.
Maybe the thumbnailer needs to create an alias unto itself, and link to it?
A thumbnailer is pretty much the perfect example of something that's
easy and useful to secure. It needs to read in a stream of data and
write out a stream of data. You could even use Linux's seccomp feature
if you were careful. It doesn't need to do anything else. Yet, here we
are letting them freely modify the user's configuration!
Yes. But you'll have to trust the modifications too. Additionally, we'll have to check the thumbnailer output to make sure it isn't trying something fishy. And then it could also impersonate another type to hide (or induce the user in running) a dangerous application.
(There's also a second problem, in that we run the thumbnailer again
for each file. 0launch isn't slow, but running it once-per-thumbnail
does add up. Long-term solution is a bit more caching, I think.)
Hum, using the thumbnailer as a process, sending it commands on stdin until a quit or a break? Would certainly helps for video-thumbnails.