At 11:11 PM 1/7/2002 +0900, Massimiliano Mirra wrote:
>On Mon, Jan 07, 2002 at 01:31:22PM +0900, Dan Sugalski wrote:
> > >integrity of a distribution, moreover downloaded over http with no
> > >notion of keys or such, I guess it should be possible to guarantee the
> > >integrity of a code library, should it not?
> > They can't, though. I doubt they do.
>
>Oh, of course they don't have *any* kind of warranty, I wasn't
>speaking legalese.

Neither was I.

> > >``apt-get program-name'' does not give very much to check. ;-)
> > It's not safe, either. And how do you know it hasn't been compromised?
>
>And how do I know the installation CDs have not been compromised?

You don't. What you do is assess the certainty you have. The install CDs 
have fewer routes of compromise than a network install. That lowers your risk.

>And, for that matter, how do I know that ruby-lang has not been
>compromised?

You don't.

>Requiring a ruby library file from a central trusted site does not
>look different to me than downloading the latest ruby tarball with
>ruby library files.

You can (though you might not choose to) look at the source you've 
downloaded. Can't do that with an automatic download.

>BTW, I don't think anybody said you'd *have* to require them remotely.
>If you want, you can require them remotely, just like if you want, you
>can install Debian packets by downloading them.  If you feel that is
>risky, just download the code, check it, put it in the library path,
>and forget that a remote require service ever existed.  I think that
>such an arrangement pretty much respects everyone's concerns and
>freedom of choice.

The one big gotcha there is that with the remote require you reduce the 
need to actually fetch and install the code you're trying to run. It all 
just happens, a

> > No, you're not likely to be a target, the same way I don't have to
> > worry much about locking the doors of my 12 year old beat-up
> > car. That doesn't make it a safe thing to do in general.
> > This is a feature that can leave a system potentially wide-open. You
> > *can't* be too paranoid in considering the potential risks.
>
>Sorry, I see the same problem with the kernel.  No end user, no matter
>how likely a target, is going to read and understand the sources
>before compiling them.

The kernel does have the same problems. One of the reasons remote installs 
of an OS (or other core system components) on production machines is unwise.

>I agree there must be ways to enforce security, but end-user checking
>doesn't appear to be a viable one.

It isn't. That means the scheme has a higher minimum level of risk.

If the system isn't low risk, perhaps re-evaluating the system to how it 
can be made low risk, is in order. And if it can't, perhaps another system 
should be engineered.


					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan / sidhe.org                         have teddy bears and even
                                      teddy bears get drunk