On Tue, 2003-09-23 at 21:27, George wrote: > Not anything really related to appfolders, but to autopackage. Reading > the above webpage I have one comment: > > To install you run the script, that completely kills any 'signing' that you > can do to a package. The user already executed code before they could check > signatures. So there is a chicken and egg problem here. Well, not really. You can still check package signatures when you are downloading from a URL given to you by the dep solver network, for instance. Of course users can download the package, check the signature with gpg themselves, then run it. Basically, the way I expect it to go is something like this: * autopackage starts young, so convenience is important for it to be accepted. Packages are frequently not checked (but then the same is true of RPMs, InstallShields, MacOS X appfolders etc also) * as it spreads, and agreements are formed on standardised dep solvers (maybe) it becomes more and more common to get your packages by running "package install foobar" or whatever, which can of course import the necessary keys, check signatures and so on. That's normally more convenient than downloading a package and running it anyway, once you've got the stuff setup (and assuming it's available via that mechanism) * The eventual "super UI" I one day dream of getting is to have packages dealt with entirely automatically - the user merely drags and drops launcher icons (well that is what we call them, to the user the icon *is* the application). So, you can drag the icon direct from the web page onto your panel, or menu, and the panel notices that the .desktop file refers to a package that isn't installed, and goes and fetches it (the icon is grayed out while this happens or something). Or, the user can click direct in the webpage. If you want to show your friend this cool new program, you drag the icon onto their Gaim window, it appears the other side (gray), and the user can click it or drag it to the panel and the right packages for their system (think cpu arch, deps etc) are downloaded in the background. That sounds unsafe, but you still get the opportunity to for instance embed public keys into the .desktop file, if you so wish, so you have an opportunity for performing crypto checks behind the users back, in effect. > 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. 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. Spyware yes, but that's placed there by the authors themselves, so digital signatures are no use. The idea is that software developers themselves write and build these packages (once), so typically if you trust the software developer, you trust the package, because they are the ones providing it to you. That leaves web server compromise being the thing it protects people against, but if you compromised the webserver you can also replace the public key file with your own. > If the concept of such a packaging scheme really takes off then it should be > easy to get different distros to package the autopackage tools. Maybe, but I'm not so sure - a "feature" has always been that it'd work even if everybody hates us :) > I don't think the signing scheme needs to be centralized. The installer can > let the user check a website for the signing key automagically somehow. And > the user could maintain a list of keys they trust. So 'vendor-a' can have > the key at 'vendor-a.com'. The installer would say to the user that the > package is signed with an unknown key from vendor-a and would allow the user > to go to the website, somehow verify that the website is the correct one > (tell the user to check the spelling of the domain name) 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...) > 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 :( > Security should really be far more then just an afterthought, but a first > class design goal of any packaging system. RPM fails at this as well as > checking signatures is harder then just installing. It should ideally be the > other way around. Not using signatures should be harder. That's why I don't > use them and don't know how to use them ... lazyness and the complexity of > using them. 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]? > Unless it's done automagically for me, I won't use them. And > same can be likely said of majority of users. To avoid such "virii" we must > however get the majority of users using some scheme like that. Well as I said, most viruses do not come from packages, especially not when the software maintainer themselves builds and hosts it... thanks for your interest! -mike ANSWERS: [1] http://autopackage.org/keys/mike or search.keyservers.net [2] lynx -dump http://autopackage.org/keys/mike | gpg --import [3] none
Attachment:
signature.asc
Description: This is a digitally signed message part