Linked by Thomas Leonard on Tue 16th Jan 2007 00:32 UTC
General Development In the Free and Open Source communities we are proud of our 'bazaar' model, where anyone can join in by setting up a project and publishing their programs. Users are free to pick and choose whatever software they want... provided they're happy to compile from source, resolve dependencies manually and give up automatic security and feature updates. In this essay, I introduce 'decentralised' installation systems, such as Autopackage and Zero Install, which aim to provide these missing features.
Thread beginning with comment 203106
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Great article, but...
by Tom5 on Thu 18th Jan 2007 17:52 UTC in reply to "RE[4]: Great article, but..."
Tom5
Member since:
2005-09-17

Otherwise anyone could create malware and provide a hash to match it, but make it look like normal software.

Yes, just because something is in the shared directory doesn't mean it's safe to run it. One reason why unfriendly names are OK here is that you really don't want users browsing around running things that just look interesting!

Furthermore, don't the archive contents have to be re-analyzed every time you want to verify their authenticity?

No, that's why you have the privileged helper. It checks the digest once and then adds it. So, if you see a directory called:

/shared-directory/sha256=XXXXXXX

then you don't have to calculate the XXXXXXX bit yourself. If it didn't match, it wouldn't have been allowed in.

BTW, you don't need to use the web to check the hash. It may be that Alice and Bob both trust the CD (in which case they get to share the copy on it). Denise doesn't trust the CD, so she checks with the web-site instead (and will share the copy only if it matches).

Reply Parent Score: 1

RE[6]: Great article, but...
by Moochman on Thu 18th Jan 2007 22:30 in reply to "RE[5]: Great article, but..."
Moochman Member since:
2005-07-06

>>No, that's why you have the privileged helper. It checks the digest once and then adds it. So, if you see a directory called:

/shared-directory/sha256=XXXXXXX

then you don't have to calculate the XXXXXXX bit yourself. If it didn't match, it wouldn't have been allowed in. <<


Is that "sha256" there before the XXXXXXX the name of the program? If so, then my fears are allayed--the name is user-readable and the user could find the program without relying on a third-party program/database.

However, I don't get the point of talking about how "this is safe if you see the hash" (or even, "this is safe if the system sees the hash"), since you say the "privileged helper" is supposed to prevent unsafe items from being in there in the first place. So malware shouldn't be able to find its way in, period, regardless of whether it has a hash directory name or not.

Which actually seems to contradict the following statement:

>>Yes, just because something is in the shared directory doesn't mean it's safe to run it.

What does that imply--that the privileged helper really isn't that effective after all? If the shared folder isn't secure, what's to prevent malware from just being copied in there, in a folder named after a hash that was generated using the same public algorithm you make available to all software publishers?

**Unless**.... every user had a unique encryption key for their individual system, so hash files generated on the system were unable to be generated ahead of time by malware authors. That would be a very secure mechanism. In that case you'd need two separate hashes--one stored online (or on CD), that is checked at install time to verify the software, and a different one on the local system, encrypted using the local personal encryption key, which shows that the file has been verified once already. That would effectively be spoof-proof, since a simple copy procedure would never be able to imitate a true Zero Install-based installation of a program. And if the user were to somehow lose their local encryption key through an OS upgrade or some such thing, no problem, they can just reinstall the software using a new key. (Actually, this kind of bears a remarkable similarity to evil system-bound DRM schemes, but it serves a much less evil purpose, since in this case it's not locking the user out of installing the software they want, it's only locking out the software they never asked for.)

>>One reason why unfriendly names are OK here is that you really don't want users browsing around running things that just look interesting!

Security by obscurity doesn't seem like much of an answer. I'd much prefer to keep my directory tree user-navigable over turning it into the filesystem equivalent of the Windows registry.

And I still can't think of a reason that any system would require the hash to be stored in the directory name.

Reply Parent Score: 2

RE[7]: Great article, but...
by Tom5 on Sat 20th Jan 2007 11:08 in reply to "RE[6]: Great article, but..."
Tom5 Member since:
2005-09-17

you say the "privileged helper" is supposed to prevent unsafe items from being in there in the first place.

No, I said that things can only have their real name. 'unsafe' is a subjective term; you can't expect the computer to enforce the rule "No unsafe software to be installed in this directory". Different users might even disagree on whether something is unsafe.

If the shared folder isn't secure, what's to prevent malware from just being copied in there, in a folder named after a hash that was generated using the same public algorithm you make available to all software publishers?

OK, take ROX-Filer version 2.5 (Linux x86 binary) for example. It has this hash (and, therefore, directory name):

sha1=d22a35871bad157e32aa169e3f4feaa8d902fdf2

You're quite free to change it in some way and add your malicous version to the shared directory too. BUT, changing it will change the hash so your evil version might be called:

sha1=94fd763dfe509277763df47c53c38fc52866eaf4

You can't make your version appear under the original's name, because the name depends on its contents.

And I still can't think of a reason that any system would require the hash to be stored in the directory name.

It depends what you want it for. I think you are thinking about this scenario:

"Alice is bored. She wants to run something, so she has a look in the shared directory to see what other users have been running. Noticing a directory called 'gimp-2.4', she decides to run it, first checking at gimp.org that its hash matches the one on the web-site."

That works fine with the hash inside the directory, but it's not the case Zero Install is aimed at. Here's our target scenario:

"Alice needs to edit some photos. She goes to gimp.org and asks to run Gimp 2.4. She (her software) looks for an existing directory with the same hash and finds the copy Bob installed earlier."

Notice that the question we're trying to answer isn't "does this directory have hash XXX?", but "where is the directory with hash XXX?"

Reply Parent Score: 1