* Martin Uecker | Tollef Fog Heen wrote: | | > 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.
Except that in practice, your build environment is no longer available. Unstable is a moving target, so you'd need to know exactly which versions were used to build a particular package. | 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. If you are looking at this as a security system, the interesting bit is not how it works, but rather how it fails. «For many packages» is therefore less interesting than the most complex packages which might embed something from the build environment, leading to not-completely-reproducible builds. | There was a thread "building packages with exact binary matches" | about it. Unfortunately, most people seem to think that this is not | worth it. I don't think that's unfortunate; I think it's a waste of resources better spent elsewhere. | > 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. Sure, but again, if this is a security system, the interesting bit is how it fails. What happens with all those complex packages which don't just have five triggers to be pulled? | 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. Am I understanding you correct in that you think just supporting installation of a subset of packages would be acceptable? I don't think it's acceptable or interesting, but you are of course free to work in that direction. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]