Hi Chris, You raise a lot of broad concerns under the header "holes in secure apt" which I'm afraid does not much to get us closer to a more secure Debian. Not many people will object that making Debian even more secure is a bad idea; it just needs concrete action, not a large list of potential areas to work on.
I suggest that you focus on one of those aspects of your email and take some concrete action to get it addressed. For example this part: Op donderdag 12 juni 2014 17:36:23 schreef Christoph Anton Mitterer: > We have a number of packages which circumvent the package management > system by downloading "normal" files (think of HTML files as downloaded > by the susv[2,3,4] packages) or even code (like torbrowser-launcher). > I think there should be some clear policy on how packages are allowed to > pull in external code/files and install them to the system: > > - How packages are technically allowed to pull in external code, I think > verifications should be mandatory and IMHO that verification should be I think a better way than to create such a policy would be to create a simple framework that does in-package downloading "right" and that downloader packages can depend on and call from their scripts (a bit like dbconfig- common). An existing technical solution will probably be more quickly adopted by the various packages than a set of requirements, and improvements need to be made in only one place. If you create something like that I'd gladly use it in the downloader package I maintain (msttcorefonts - which does check hashes of downloaded stuff, btw) and I'm willing to spend time with you on the integration and to see what may be required or missing for my package to use it. If we show that it works for this package, others will surely follow. You just need to take the first step. Cheers, Thijs
signature.asc
Description: This is a digitally signed message part.
