hi everyone,
On Mon, Aug 10, 2009 at 02:47:16PM +0200, Patrick Schoenfeld wrote:
> On Mon, Aug 10, 2009 at 11:47:31AM +0100, Neil McGovern wrote:
> > Comments appreciated, I'd like to get these all in and integrated by end
> > of August, to push to the policy team for inclusion.
i took a checkout of the latest svn and don't see anything there, are you
working on a local copy?
> "3.5 Security measurements"
>
> is interesting. However I fail to see how this relates to packaging
> webapps. Do we really want to impose additional policy on which
> standards software must fulfill to be included in Debian?
> If so, then.. where to draw the line? Imposing it on webapps only
> seems a bit inconsequent.
i think what distinguishes a webapp package from a standard software
package is the fact that the primary use case involves acting on input
from untrusted third parties. i think you're right though; there's a
risk that we might be trying to micro-manage this a bit too much, and
some of the specifics (like register_globals) really shouldn't be in
the webapps policy but instead the php policy, unless they are only
illustrative examples. i.e. instead of:
<p>
PHP applications must not depend on
the "register_global" setting turned
on in Apache or other httpds.
<p>
PHP applications should take extra
care not to use internal variables
before their initialisation, in case
"register_global" is turned on by the
administrator.
have:
<p>
Web applications that are configured by default to be publically
accessable[1] must not rely on features or particular
configurations of a webserver or scripting engine that are
considered to be insecure[2]. For example, applications must not
depend on the "register_globals" setting in the PHP scripting
engine
On Mon, Aug 10, 2009 at 03:59:24PM +0100, Neil McGovern wrote:
> On Mon, Aug 10, 2009 at 04:02:46PM +0200, Dario Minnucci (midget) wrote:
> > 'Webapps Policy' --> 4.1.1 Includable files for web applications
> >
> > Please, include a paragraph about 'site-wide' includes and the
> > preferred path for them.
>
> Added this, thoughts?
>
> site-wide include files should be split into a different package,
> and made available in
> <file>/usr/share/<var>NEWPACKAGE</var></file>. This is to avoid
> having multiple copies of code in different packages.
I'd say that site-wide include files should defer to the respective
language policy documents, with an aside that suggests something along
these lines. how about this:
When applicable, site-wide include files should adhere to the rules
and conventions of the respective language policy documents[3]. Otherwise,
a directory location similar to the application-specific includes path can
be used. The files should be provided in a package separate from any
web application or otherwise unneeded dependencies, to allow for re-use
and eliminate multiple copies of the code in different packages.
On Mon, Aug 10, 2009 at 11:23:57AM -0500, Romain Beauxis wrote:
> Le lundi 10 août 2009 09:59:24, Neil McGovern a écrit :
> > site-wide include files should be split into a different package,
> > and made available in
> > <file>/usr/share/<var>NEWPACKAGE</var></file>. This is to avoid
> > having multiple copies of code in different packages.
>
> When splitting files into share and var locations, static files go to share and
> editable/dynamic files to var.
>
> However, a lot of PHP code, for instance, rely on relative path for their
> inclusion, which is not compatible with this: as soon as a file from share
> calls for the inclusion of a file that is in var using a relative path, this
> will fail.
i think the application should be responsible for setting its include
path, which is easily doable with a centrally included debian file or
apache configuration. i realize i'm a bit of a hypocrite for saying
this because i'm using a set of symlinks in the cacti package, though :)
> Hence, to make this work, I add:
>
> /usr/share/application/static.html
> /usr/share/application/dynamic-folder -> /var/lib/application/dynamic-folder/
> /var/lib/application/dynamic-folder/
> /var/lib/application/static.html -> /usr/share/application/static.html
apart from what i said above, i think it's important to use
unique subdirectories of the top level package directories
(i.e. /usr/share/application/htdocs/static.html).
On Tue, Aug 11, 2009 at 02:26:36PM +0800, Paul Wise wrote:
> I suggest mentioning /home alongside /srv etc in 5.1.1 and 3.1.
seems reasonable.
> 3.3 mentions /usr/local/PACKAGE, IMO that should be /usr/local/share/PACKAGE
yes, good catch :)
> I also wonder how /usr/lib/cgi-bin/ interacts with multi-arch.
TBH, i think we should deprecate/disallow the use of this directory. All the
years of bikeshedding about /usr/lib/cgi-bin vs /usr/share/cgi-bin aside,
I think it's a fundamentally wrong idea to drop remotely executable
files in a location where they are by default turned on even if the
application isn't configured.
On Tue, Aug 11, 2009 at 03:32:09PM +0100, Neil McGovern wrote:
> On Tue, Aug 11, 2009 at 02:26:36PM +0800, Paul Wise wrote:
> > /usr/share/PACKAGE/htdocs also gets used for static content, I wonder
> > about adding that to 3.1.
>
> It's currently got:
> "A unique subdirectory of /usr/share/PACKAGE"
> which should cover this. Do you think it's worth adding htdocs as an
> example?
I see no harm in doing that.
On Tue, Aug 11, 2009 at 08:31:07PM +0200, Penny Leach wrote:
> One thing that seemed to be missing (forgive me if I'm wrong) is where to
> put user-uploaded content. The closest thing I found was "Modifiable and
> overridable content" which lives in /etc/packagename/, but that clearly
> seems wrong.
>
> In the case of, for example, Moodle, we're currently designating
> /var/lib/moodle to hold all content that is uploaded by users (through
> Moodle, not via dav or any other mechanism although I guess that could be
> included).
I'd say moodle is on the right track there, maybe we should add a
subsection that enshrines this type of behavior (i'd once again make
the amendment that it should be a unique subdirectory)? then again i
guess it might be duplicating what's already specified by the FHS.
sean
[1] we might want a footnote to define publically available, which in my head means
something like "network accessable".
[2] some definition of who determines what insecure is needed, and who
gets the final say.
[3] link/footnote to language policy references
--
Attachment:
signature.asc
Description: Digital signature