On Sat, Jul 12, 2008 at 2:57 PM, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > On Sat, 12 Jul 2008 19:28:10 +0200, Lucas C. Villa Real <[EMAIL PROTECTED]> > wrote: > >> On Sat, Jul 12, 2008 at 2:13 PM, Jonas Karlsson <[EMAIL PROTECTED]> wrote: >>> 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? >> >> Yes and no. Viewfs still needs to know about $goboPrograms to create >> the virtual dependencies tree on demand. $goboIndex is coming to save >> us from headaches of having different programs hardcoding different >> prefixes. The ability to move applications to outside $goboPrograms >> was never intended to be the reason of that change. >> > No, but it is an effect and I don't think we should work against that by > implementing a filehash that doesn't support it. > >>> 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). >> >> At least we hope so. We'll always have to post-process the installed >> files to check that (grep'ing for $goboPrograms on them should be >> enough). >> > Yes, we do this post processing and thanks to this most applications *are* > relocatable, since they will use /S/L (or /S/I), so I still don't see why > we shouldn't work with it instead of against it.
As I told above, ViewFS needs to know about $goboPrograms, so applications linked in /S/I that are stored outside that dir *will just not work* -- especially if they contain libraries that other applications depend on. -- Lucas powered by /dev/dsp _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
