On Sat, 12 Jul 2008 19:07:47 +0200, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 12, 2008 at 11:34 AM, Jonas Karlsson > <[EMAIL PROTECTED]> wrote: >> On Sat, 12 Jul 2008 01:43:32 +0200, Hisham <[EMAIL PROTECTED]> wrote: >> >>> On Fri, Jul 11, 2008 at 3:56 PM, Jonas Karlsson <[EMAIL PROTECTED]> wrote: >>>> On Fri, 11 Jul 2008 20:27:15 +0200, Hisham <[EMAIL PROTECTED]> wrote: >>>> >>>>> On Fri, Jul 11, 2008 at 1:01 PM, Jonas Karlsson <[EMAIL PROTECTED]> wrote: >>>>>> On Fri, 11 Jul 2008 16:37:51 +0200, Hisham <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>>> On Fri, Jul 11, 2008 at 3:43 AM, Jonas Karlsson <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>>> There has been a proof of concept where a group of people has injected >>>>>>>> bad packages into a distribution by asking to be a mirror and providing >>>>>>>> erroneous updates (1). >>>>>>>> The issue is not that they provided spoofed, hacked or broken packages, >>>>>>>> which would fail with bad signature (or the user had to add the key to >>>>>>>> their keyring), but they used old packages which they updated version >>>>>>>> information for. An example for GoboLinux would be to repack an old >>>>>>>> version, Foo--1.2--i686.tar.bz2 as Foo--2.3--i686.tar.bz2 and our tools >>>>>>>> would be fooled to thing that the latter was an update/later version >>>>>>>> (you would also change the name of the version directory in the >>>>>>>> tarball). >>>>>>>> This meant that users that used that "mirror" would get "updates" that >>>>>>>> wasn't always up to date and even might have security issues. >>>>>>>> We need to add version information to our packages, any idea on a good >>>>>>>> scheme for that? >>>>>>> >>>>>>> Yes, we just need to add the full path to the FileHash file entries. >>>>>>> If they are tampered with, FileHash.sig will alert. Fix committed to >>>>>>> svn. >>>>>> >>>>>> I don't think we should use *full* paths, only <program name>/<version>. >>>>>> People might not have $goboPrograms at /Programs. >>>>> >>>>> These people better not use the binary packages, for tricky troubles >>>>> await them if they do. >>>>> >>>> That depends on how they are built. Lucas has made successful builds >>>> against >>>> /System/Index, meaning that the binaries doesn't reference /Programs at >>>> all. >>>> That also means that packages can be placed anywhere, as long as they have >>>> symlinks in /S/I. One can, already today, install binary packages at any >>>> prefix and just symlinking them, with none or very little breakage (depends >>>> on application). I think we should cover these cases, especially as we will >>>> have them in the future. >>> >>> People who are willing to go through this "very little breakage" >>> should know what they're doing, in which case they can bypass the >>> check. I never wanted programs to be installed outside of /Programs >>> (hell, that's why GoboLinux was created in the first place! to end the >>> proliferation of locations where apps were installed!). If you want to >>> encourage this behavior, go ahead and revert. >>> >> I don't think you're on the wrong track, just that <app>/<version> would >> suffice and that would also support relocation better. There might be people >> that has applications on a NFS mount, which would not be supported with the >> current FileHash implementation. All we need is a record of app name and >> version, that are signed, somewhere and check them against what we think it >> is, which we get from parsing the tarball name. > > Unless the applications mounted from the NFS share are relocatable, > union-mounting that share over /Programs would be the most portable > solution. > What am I missing here? If an application is built against /S/I its files can be placed anywhere, as long as it's symlinked to /S/I, right? And for those applications that are built with current patch can be relocated as long as they don't reference its own prefix (which most of the times isn't the case afaik). -- /Jonas Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
