From: Thomas L. <ta...@ec...> - 2003-10-29 12:10:27
|
On Tue, Oct 28, 2003 at 03:48:06PM +0100, Joachim Kupke wrote: [...] > Just to check what offline signatures are: > > - I provide some software from my site that---inadvertently, of > course---is exploitable, perhaps even root-exploitable. > - I fix this, but your (perhaps virtual) proxy server continues to give > you the old version. > - Your version of the software is still flawed, although I have done my > best to fix it as soon as possible. > > How would I actually "prove that [your] site is doing anything wrong?" The site isn't doing anything wrong. It's the broken web proxy that's ignoring the do-not-cache request we send that's broken. And easily checked by getting someone else to download it. [ zero knowledge signatures ] > The difference is that while Alice and Bob have only obtained a proof > that they cannot use to prove their observation to somebody else, in But *why* do we want to do this? What possible use does it have except for allowing illegal software distribution and trojans? > your scheme, they can use the data they gather in order to calumniate > you. Sure, you have been a bad guy sending a trojan, but determining so > should be the authorities' responsibility, not Alice's or Bob's. This doesn't make sense. If a site is distributing trojaned software then I should be able to warn other people about them, with proof (ie, "don't trust this key"). If it was an honest mistake then people can judge that for themselves, but the evidence must still be available. [...] > Anonymity is no problem at all. You are distorting my point. > What we are gaining is that men in the middle cannot inject flawed > software into the zero install directory tree on the one hand Stopping out-of-date (but signed) software is easily done with GPG signatures by including an expirey date. The index can be signed on each request (as with zero knowledge) or once an hour or whatever. However, anyone who could perform this attack against zero install could also do it against every current software distribution system (RedHat network, rpmfind, Debian, kernel.org, etc). It doesn't seem to cause any problems. Also note that if I tell you that I've released a new version of my software (eg, though a security bulletin) then you won't be fooled because 0refresh will check the date for you. On the other hand, zero knowledge is inherently insecure, because you have to store the secret key on the server. And not just on the server, but readable by a CGI script! (of course, allowing CGI scripts weakens the security of your server too). Imagine if someone tried to use a zero knowledge script on SourceForge! > and that sites that are unwilling to sign every bit of information that > they serve can still trustfully transmit their data. Why would they be unwilling to sign it, though? Using free software requires a certain amount of trust, but I'd be pretty suspicious of someone who was taking such precautions... (mind you, I sign all my stuff anyway). Remember that companies using https, ssh, scp, etc are all encrypting everything they send you. It's just good practice. > > seem designed only to allow even easier illegal distribution of software, > > which doesn't interest me. > > I do not think that Shamir as one of the pioneers in cryptography had > had illegal distribution of software in mind when he devised zero > knowledge protocols. Neither had I when I suggested using them. It sounds like zero knowledge is useful if you control who you do the signing with. If I contact a jouralist and leak some information, it may be useful to prove that it came from me without the jouralist being able to accuse me later. It will be their word against mine. Fine. But if I do this with a thousand jouralists, can I still deny it was me when they all accuse me? No, because it's a thousand people's word against mine. This is what the situation would be with zero install. > What if they find Microsoft code in GTK (in order to give an extreme > example)? It would be hard work to get rid of GTK (or to rewrite the > affected parts, perhaps), but it could be done. But Microsoft may have > collected your signature on rox.sf.net and will now sue you because your > users have benefitted from their code. That may be the legal part that > you are trying to solve in the next paragraph, but... They can try. What court would convict me? Unless they can prove I did it knowingly (in which case it is quite right that I should be found guilty). [ path hashes ] > > In fact, it's worse because it hides the server. > > Why should it? Any path component that's 40 characters long, most of which are random, is going to be difficult for users to check carefully or spot errors in. > > If paths look like this: > > > > /uri/0install/192.168.0.1,34jJHKkJhkfkjhif743kkjsmnazkrf734jdjgfgfkajfdfddfdk/rox > > You are exaggerating. We were looking at way shorter path names. How long, then? 30 random characters is about the minimum you can get away with. > I don't see how this would be different to making > u0i/rox.sourceforge.net a symlink to rox.sourceforge.net,blahblah. Of > course, if we could promise that u0i/site/.0inst-key* file names can > never be allocated unless there is a valid signature, the above would > work. Names beginning with '.0inst-' are disallowed from index files (see index.c:169). > > Basically, I think you're being way too paranoid. > > Just because you think they are after you doesn't mean they are not. :-) > > > There are plenty of weaker links in the chain than Zero Install. > > Name them. You don't know any of the people writing this software. All this system does is slightly increase the chance that the software you're downloading from a server in France really is written by the same people you don't know anything about that the authors of the software you downloaded from some people you don't know anything about in Australia trust. Even if you trust these people, they may make mistakes. Indeed, your argument about re-injecting old software into the system relies on authors having made mistakes in the past. The answer to the security problems is not to find a way to have 100% trust in someone, but to make sure that such a level of trust isn't needed. Why should I have to trust the abiword developers in the first place? It loads a file I give it, lets me make changes and saves the result. Abiword should not be able to delete my files, email out my credit card details or change my spreadsheets. At worst, it may save back a corrupted version of the file (at which point I click on Undo in the filer to recover the old version). Of course, we can't do this easily at the moment (but neither is it common or easy to perform the attacks you suggest). However, zero install moves us closer to this goal. [...] > Acknowledged. But what you are saying is still a bit rough. Does it mean > that for some packages, having them under zero install requires major > restructuring by their authors? Assuming they don't allow plugins to be installed outside of their prefix (ie, no user plugins). I can't think of any programs that actually have that problem, but there may be some. [ backgrounding ] > That is why with daemontools, every daemon is restarted (after pausing > for a second) when it exits. In the above example, gdm may fail once or > twice, but after zero install is up and running, gdm will also come up. This kind of thinking is why Linux takes so long to boot. It's very simple: you need to be notified when zero install starts, and when it stops. Preferrably without polling. You can do it like this: zero-install gdm & while true; do dbus-pause-for /var/cache/zero-inst/.control zero-install done (where dbus-pause-for opens a connection to zero install and returns if that fails or when the connection is closed) No need for sleeps slowing everything down. You can't do this unless zero-install backgrounds itself (admittedly, it would be even easier with a system-wide dbus, since you could then get both events that way). [...] > Updating the naming scheme may be complicated: Binaries will be linked > against ..../Linux-ix86/.... right now. Yes, Linux-ix86 will always be the name of that platform. New platforms get to choose their own names. They're just unique identifiers. [...] > dietlibc is meant to be linked against statically. Yes, statically. If > there is a bug in dietlibc, you must relink your program. OTOH, dietlibc > usually gives smaller static binaries than glibc gives dynamic binaries. > Plus, they are usually faster. All that comes at the additional price of > incompatibility to glibc. From the dietlibc FAQ: OK, so I link ROX-Filer against dietlibc. GTK is linked against glibc. Does this mean: a) I have to load almost twice as much code as before, or b) That when a glibc function tries to call a GNU extension (eg %m in printf) it will get the dietlibc version and fail? If so, I don't see the advantage. Although it could be useful for very small programs with no dependancies. [...] > Out of fairness, I think, we should be pretty sure that things like the > index format do not change. If people start using it, we can maintain compatibility easily. I've tried to keep newer indexes working with older clients, but not the other way around (since you're the only other site maintainer I know of). I have a vague idea that the new href attribute may have failed the strict XML schema check in some older versions, but noone complained. If anyone had, I could have done it differently. > > What's that got to do with XML? > The most natural way to think about such a tree with meta data is a > relational database. I guess you've been using tables way too long, if they seem more tree-like than XML ;-) > That is the reason why you have had to move the "href" attribute around. The new href has a different meaning. Before, it was the path relative to the index file. Now, it is a path relative to a mirror. You need two separate attributes for this, because they have different values and meanings. > Of course, there is no guarantee you would automatically have picked an > ideal table design in an SQL database. But chances would have been that > you could have added backward compatibility views to a new table design. If I broke backwards compatibility, it was only because noone complained and I didn't notice. -- Thomas Leonard http://rox.sourceforge.net tal00r at ecs.soton.ac.uk tal197 at users.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |