Re: ssl security desaster
* 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
Reply to: