Re: spatial stuff detail

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

> 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

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 ''.  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

> 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

[1] or
[2] lynx -dump | gpg --import
[3] none

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]