hi everyone,
Post by Patrick SchoenfeldPost by Neil McGovernComments 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?
Post by Patrick Schoenfeld"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
Post by Patrick SchoenfeldPost by Neil McGovern'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.
Post by Patrick SchoenfeldPost by Neil McGovernsite-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 :)
Post by Patrick Schoenfeld/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).
Post by Patrick SchoenfeldI suggest mentioning /home alongside /srv etc in 5.1.1 and 3.1.
seems reasonable.
Post by Patrick Schoenfeld3.3 mentions /usr/local/PACKAGE, IMO that should be /usr/local/share/PACKAGE
yes, good catch :)
Post by Patrick SchoenfeldI 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.
Post by Patrick SchoenfeldPost by Neil McGovern/usr/share/PACKAGE/htdocs also gets used for static content, I wonder
about adding that to 3.1.
"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.
Post by Patrick SchoenfeldOne 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
--