[gentoo-dev] Re: how to handle sensitive files when generating binary packages
Matthias Schwarzott [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 20 Jun 2007 15:15:20 +0200: On Mittwoch, 20. Juni 2007, Olivier Crête wrote: I will claim that almost any file in /etc is potentially sensitive (even if it does not contain passwords, if may contain other informations interesting to a cracker). And even if we did what you propose, we'd run the risk of missing some and giving the user a false sense of security. Maybe we should document somewhere that the only way to make bin pkg that are safe for public distribution is to do emerge -b or -B .. And that pkgs built with quickpkg may contain sensitive information. If there is smart conf-file updating inside pkg_preinst(), I think even emerge -b could be unsafe. If so, then something is broken. pkg_preinst is for stuff done to the /live/ file system (as opposed to the fake install, which is what's packaged), according to the ebuild (5) manpage. As such, it should be done when the binary package is actually merged (qmerged), since said binary package may be (and often is) installed to a system other than the one it was compiled on. If pkg_preinst is modifying as-shipped bin-pkg config files based on the live filesystem of the build system, not the target system, something's seriously broken. If it's not, then it's not unsafe after all, at least not in this context. In this regard, -b/-B behavior should be identical. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: how to handle sensitive files when generating binary packages
Oh yeah,and who said we really needed more than one use case? I think providing tools to allow Gentoo to be adopted in the corporate environment is reason enough to have binary package support, and I feel that many people will agree with me. Well I'm sure you'll be over the moon to know I do ;) The issue isn't whether or not we should have them, or for that matter whether or not there is more then one use case. The issue is making sure that we know what the use cases are to ensure that the tools we have are flexible enough to be able to support every case and so that we don't paint ourselves into a corner by making decisions before we know how people plan on using the tool. Agreed, but the actual mechanism in question is only adds functionality; nothing is being taken away aiui. As to it borking use cases, surely it's better to explain which use case it breaks than get into a nitpick about whether there might be any others. After all that's why there's an externally-facing list: so people can chime in with their concerns. The discussion on default policy doesn't change the fact that it is a needed mechanism, imo. Having it as a switch in FEATURES makes a lot of sense, and i think that ensuring Gentoo systems won't leak sensitive information, unless explicitly told to, is a worthwhile objective. A warning when adding sensitive files to a binpkg seems like a wise idea, especially if it is a set and forget flag. (Devs can always tweak an env var, users who've lost data are harder to mollify.) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: how to handle sensitive files when generating binary packages
Andrew Gaffney wrote: Ciaran McCreesh wrote: Andrew Gaffney wrote: I'm not sure that's really a feasible solution (but then you probably weren't suggesting it with that intention). Being able to create a backup of any installed package without re-emerging is pretty handy. Many people use it and there would be a revolt if quickpkg were removed. Then live-filesystem-generated packages could be marked as 'not for redistribution'. That's certainly a lot more feasible. However, it would have to be marked in some way that portage would recognize, and that marking could still likely be easily removed. It's more feasible than banning the creation of packages from a running system, that's true. The original solution doesn't seem so infeasible to me though.. I have a feeling this is more about an alternative bin format ;) This still allows the social engineering attack. Someone can get a binpkg created with quickpkg of someone else's baselayout and then remove the marking that would make portage gripe. Agreed. As a user, I'd much rather just be able to quickpkg whenever I choose, and know that the system will not allow sensitive files to be copied. Starting with /etc/shadow and the like is great by me, as I'm fairly sure there'll be a sensible plain-text config file I can edit by hand if I need to. If I were to allow such files to be copied, I'd like a warning. Yes I mess up sometimes, so what? I'm the user, it's expected ;p -- [EMAIL PROTECTED] mailing list
