hey again, On Tue, May 03, 2005 at 05:36:42PM +0200, Pierre Habouzit wrote: > well, I really believe we can have support of the QA and Security teams > on this. yeah. maybe i'm just being a little overly pessimistic. then again, when you're a pessimist, you often end up being happily surprised :) > this is not satisfying IMHO. or we need a fancier conffiles manager that > allow other options than 'ignore change' or 'drop your file' and allow > some merging facilities like the gentoo etc-update does. i think that makes it a problem outside of the scope of web apps, then. On Tue, May 03, 2005 at 05:39:43PM +0200, Thijs Kinkhorst wrote: > > if there is some minimalistic requirements, I really believe we can > > drastically reduce the possibility for such problems to arise. > > Another problem here is the question who can or should enforce these > problems. well, the idea is that we draft a document, get enough support for it to become official policy, and then you can file rc bugs against any package that violates the policy. On Tue, May 03, 2005 at 06:04:54PM +0200, Pierre Habouzit wrote: > > security nightmare, but that has been dealt with and the package will > > be removed. Isn't the current practice sufficient? > > I prefer prevent than deal with. or at least "raise the bar" a little bit. On Tue, May 03, 2005 at 05:39:44PM +0200, Alexis Sukrieh wrote: > Yes, so, basically, the question is: > > Should we consider the templates (and other static files) customizable? > The more I think about that issue, the more I think we should not. i agree. or at least, as a default answer (where if they are, they are treated as configuration files). that makes life much, much easier for us, and if it's documented in policy that this is the way things are, then the local admin only has themselves to blame. they can always just install the package and copy the files somewhere else if they want to really get down and dirty with the customizing, or *gasp*, go outside of the package management system! > Let me take bugzilla again as an example. > Templates changed a lot between 2.16 and 2.18. If I provided it as > conffiles, user would be overkilled by merging questions when upgrading from > 2.16 to 2.18, even if he didn't changed anything in the templates. i don't know enough about bugzilla or its templates, but i get the point. istr ucf being able to handle that (skipping versions), but i could be mistaken. in any case, we should definitely keep in mind that such situations are very real. if ucf would handle this, we could probably provide a script that recursively applies ucf over the contents and give the option to run it at install time. i kind of like that idea, actually. what do you think? On Tue, May 03, 2005 at 05:42:22PM +0200, Thijs Kinkhorst wrote: > Indeed. We should allow the shipped templates to be *overridable* instead. > The shipped templates are not to be modified (hence somewhere under /usr) > and a user can override those templates by adding his own to some other > dir, probably under /etc, where the web application will pick them up if > present. unfortunately, this puts a lot of burden upon the maintainer, and in some cases may not be possible at all. On Tue, May 03, 2005 at 05:43:30PM +0200, Pierre Habouzit wrote: > a lot of web apps are extensible (drupal, wordpress, ...) and users may > want to use such plugins. This is unlikely that we may be able to > provide packages for any of those plugins, and we should think at a way > to allow users to use their own plugins, without totally breaking the > upgrades .... istr egroupware handling this. of course, "plugins" are completely different in every application, and i don't imagine there is a common way to handle them. there's probably a generalization that we could make here, like telling packagers they put something under /usr/local where plugins can go. On Tue, May 03, 2005 at 05:50:19PM +0200, Pierre Habouzit wrote: > I disagree here. Some web apps live by the fact that they are skinnable > (think at a blog e.g.). I agree that even if phpmyadmin is skinnable, > most users will live with default skin. same for a webmail (up to some > point : portal admins may want to make it match the aspect of the > portal). well, these skinnable apps usually have a "themes" (or at least "css") directory of some kind, which is much easier to manage and keep under control as config files. for apps that don't provide this, i'm going to re-iterate that we could make everyone's life much easier if we draw a line in the sand and say that regular static files are not modifiable, and file wishlist/upstream bugs with the authors asking them to provide such a way. > If admins ahve to maitain an rsync mirror and god know what else, and > that they would have to perform all upgrades manually, etc ... I don't > see the point in using debian packages for that. they can achieve that > using pristines tarballs. well, at the least they could be informed when there's an upgrade, which could still be helpful for security reasons. sean --
Attachment:
signature.asc
Description: Digital signature