On Tue, Sep 23, 2003 at 10:12:28PM +0100, Mike Hearn wrote: > > So to avoid "linux virii" spreading desguised as packages I would recommend > > requiring download of the autopackage tools instead of running the package. > > Maybe, but I'd need to see pretty strong arguments. Requiring a download > of the tools basically implies that you won't allow an installation > unless the user has already imported the public key - it's hard enough > finding everybodies public keys simply for email! Realistically it's not > reasonable to expect people to learn GPG (and require a network > connection if we want to do it automatically) in order to install > software. That's because the UI for these things is complete and utter crap. GPG is really an aftertought in the way it works. You talk of a *good* and *easy* UI for the installation process, why not have a *good* and *easy* UI for signatures and security. Just because nobody still hasn't done it right doesn't mean that we should continue to do it crappily because 'that's the way it works'. > I'd also note that for years, people have been downloading and > installing software using standalone installers on Windows and I've > *never* heard of somebody being cracked because of a trojaned installer. See comment below. I'm not worried about trojans (though people tend to underestimate things that haven't happend much yet), I'm worried about the 'executing' virii like the recent outlook ones. Read on below ... > eek! There is no good way for users to know they are talking to the > right website. The only real way is to use SSL then tell users to check > the certificates, but most users are only vaguely aware of the little > lock in the first place in my experience - checking the cert every time > is almost certainly beyond most (i don't even bother most of the > time...) Thinking more about it, it is possible. Suppose you get a package signed by redhet.com rather then redhat.com. Well obviously to the installer this is a new domain name for the installer. But it could do a little bit of heurestic and tell the user about this something like: "This software appears to be from redhet.com which is a very similar name to Red Hat (redhat.com). The package has not been signed by Red Hat. If you still want to continue, please press the 'Yes I want to screw myself' button." You get the idea. > > I think for this to be used, signing and checking of signatures must be more > > then an optional afterthought. The tools should really give nefarious > > warnings about unsigned packages. We really don't want to get into the > > whackiness that is the outlook executable virii world of windows today. > > Outlook viruses (and other forms of windows virus) really have nothing > to do with packaging, and everything to do with: > > * easily duped users (see how authentic W32/Swen looks!) > * buggy/old email clients like Outlook Express which run code on preview > > Unfortunately there's not a lot you can do when a user decides to > download an executable attachment and run it - all the signatures in the > world won't stop that :( Yes there can. Think very nefarious dialogs that pop up when you try to do it. The email client should be very careful here about warning the users. A nice signed package from someone we trust should pass without any dialog here then (if security is done right). You should just be able to click on it or dnd it or whatnot. If W32/Swen looks authentic then it would loose all authenticity if a dialog came up that told you that "no this package was not distributed by microsoft.com, but in fact by micros0ft.com". Obviously some people would still be fooled but I'd say a significantly lower portion. If you make installing apps very simple you must also make checking authenticity very simple and if at all possible as transparent as it can be. One of the reasons for the necessity of good and easy checking of authenticity is that the power of the 'nefarious dialog' lessens if it's given for even safe things. For example if real microsoft updates also would get such a dialog, then the user would be conditioned to just OK it because it's a stupid dialog that says absolutely nothing. Another idea would be for nautilus (or any filemanager) make a hash of all trusted binaries (binaries in system dirs could be trusted implicitly), then it can check and again come up with nefarious dialogs for unknown things. > Ah, well exactly. I signed this mail to make you happy ;) but where do > you get my public key? [1] How do you import it? [2] If even us coders > don't bother, how many users will [3]? That's because GPG sucks donkey balls in terms of user experience as do most security packages currently. One appears to need a degree in cryptography to understand even the description of some packages. Just because the current user experience sucks so badly, doesn't mean that it always needs to be that way. Most of the time currently it is as I said an afterthought. Something you as a user have to do extra. And you have to do a lot of work that can be automated. Local installed software can be trusted and thus can do the 'checking' and 'verifying' and all that for you. Remote software must be checked. > Well as I said, most viruses do not come from packages, especially not > when the software maintainer themselves builds and hosts it... But if it's easy to install packages, someone will start distributing virii as such. I'm not saying we're well prepared for the 'random binary' execution scenario either. > ANSWERS: > [1] http://autopackage.org/keys/mike or search.keyservers.net > [2] lynx -dump http://autopackage.org/keys/mike | gpg --import > [3] none ANSWERS for me: [1] nowhere [2] nowhere (But I do have a GPG key and will sign this mail, but obviously you don't know that it's been signed by me so ...) George -- George <jirka 5z com> If all economists were laid end to end, they would not reach a conclusion. -- George Bernard Shaw
Attachment:
pgpykwBfKpd0w.pgp
Description: PGP signature