Tollef Fog Heen wrote: > * Martin Uecker > > | Another problem I have argued about before, not directly related to this > | incident, but IMHO another desaster waiting to happen: There is no > | way to independetly validate that a debian binary package was > | created from the corresponding source. > > How would you go about doing that? If you just mean «all packages > should be built on the buildds», that's fairly easy to do, but if you > are talking about actual verification of source => binary which can be > done post-mortem, that's much harder. Actually, it's not that hard. If you build a package in a controlled environment, you get something which is in most cases already very reproducable. For many packages there are only a few time stamps which somehow end up in the built that make it non-reproducable. Since these time stamps are not really usefull anyway they could simply be removed. There was a thread "building packages with exact binary matches" about it. Unfortunately, most people seem to think that this is not worth it. > | What bothers me too is the fact that the installer scripts of all > | packages have root permissions during installation. While this might > | be hard to do, in principle I see no good reason why installer > | scripts could not be limited to certain tasks. > > I believe that postinsts need the flexibility shell (or perl or python > or whatever) gives them. If you want to restrict postinsts to only be > able to do a limited set of operations, the quality of packages will > detoriate quite a bit as they are no longer flexible enough to cater > for all packages's needs. A lot of packages have very simple scripts often only updating some kind of index after installation which could be done with triggers. In these cases, the scripts could possibly removed completely. Checking that the package does not overwrite files from other packages and installs files only to certain directories would then limit the security risks from installing the package to the users of a system which actually do use the software. In other cases, it might be possible to lock the scripts down with selinux, as Manoj pointed out in the thread mentioned above. Regards, Martin
Attachment:
signature.asc
Description: Digital signature