[Pkg-javascript-devel] Debian javascript URLs

[T.C. Hollingsworth]

On Wed, Aug 21, 2013 at 8:23 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> sorry to be late to the discussion!
>
> I quite like the idea that we can make it easy for web site
> administrators who use debian (and fedora!) to avoid the evil CDNs for
> their standard javascript.

No problem, thanks for chiming in!

> On 08/15/2013 08:40 PM, T.C. Hollingsworth wrote:
>> There's nothing wrong with it, I just think we should have something
>> shorter and less likely to result in an uproar.  I'm happy with making
>> it work, so you can just share /usr/share/doc as /doc and everything
>> can work fine.  That makes a lot of sense to me.
>
> fwiw, we recently *stopped* sharing /usr/share/doc as /doc due to
> CVE-2012-0216:
>
>  http://www.debian.org/security/2012/dsa-2452
>
> So if we do this, we need to take some pains to be sure that this sort
> of approach doesn't re-introduce the problems resolved there.  Do you
> have any suggestions of how we could comprehensively avoid those problems?

I wasn't aware Debian had disabled this.  The last time I checked a Debian
system it was enabled by default, so I was concerned with keeping compatibility
here.  It looks like it's a non-issue these days.  ;-)

It's probably a good idea to let administrators turn this on so they can make a
decision about the security tradeoffs and disable any dynamic stuff like PHP as
they need to.  It'd be nice if Apache had a single configuration option to
disable all dynamic applications in a directory or vhost.  That would avoid this
issue nicely, but unfortunately, that really isn't possible right now.

Note that the web assets directory should avoid this security issue primarily
via distribution policy.  Dynamic applications are outside this directory's
scope and should never, ever be included inside it. For defense in depth we can
disable ExecCGI and mod_php and other common  dynamic application modules in the
Apache configuration as well.

>> It doesn't make any sense to me to hardcode a filesystem path into
>> applications written in dynamic languages that you'll never be able to
>> just open with Firefox anyway.  There's a reason there's a separate
>> namespace for content served over HTTP.
>
> Jonas' argument to just use the filesystem hierarchy for select
> directories is tempting (and feels logically the most satisfying), but i
> suspect the complaints (about URL length and panic about exporting /usr)
> that the fedora folks are trying to address or head off will be real
> enough, even if they're not logical.
>
> It occurs to me that if a single top-level directory (e.g. /.websys) in
> the URL namespace was mapped to a "safe" directory in the filesytem,
> then people who wanted the feature Jonas is asking for can simply create
> a /.websys symlink in their local filesystem to get the same benefits
> without requiring web sites to have huge URLs in their <script> tags.
>
> breaking that into two separate top-level directories seems more likely
> to raise objections to me -- just do it once and be done with it.
>
>   /.websys/js
>
> is still as short as
>
>   /javascript
>
> and permits /.websys/fonts, /.websys/css, etc to reside under the same link.
>
> About the example name used above: i made up ".websys" for a couple
> reasons, neither of which are particularly important, just trying them
> on for size (if you have a link to the discussion that concluded with
> _sysassets, i'd be happy to read the other issues and options fedora has
> already considered):

The Fedora discussions regarding all this can be found in [1] and [2].

>  * leading dot makes the file "hidden" so most normal views of / won't
> see an extra entry in case someone decides to add the symlink to the
> root filesystem.

Our httpd maintainer suggested dot-prefixing this directory before, but didn't
really make an argument as to why. I had never really considered that a symlink
to it might exist in a directory that has listing enabled.  That's a good reason
to dot-prefix it.

I'd be happy to swap out the underscore for a dot, then.  Note that Fedora
already plans to disable directory listing in this directory by default.

>  * including "web" in the name gives people who find the name in the
> filesystem a hint about what it's for, just like "sys" gives people who
> find the name in a URL a hint about where it comes from

Well the idea with our naming was to emphasize the "web" aspect on the
filesystem, where the "system" aspect is already obvious by the fact that it
exists in /usr/share, and to emphasize the "system" aspect in the HTTP path,
where the "web" aspect is already obvious by the fact that it is an HTTP path.

I chose the "assets" term because I really wanted some sort of noun by which
this stuff could be identified by.  The only other suggestion that came up in
the Fedora thread was "lib" or "libraries", but that doesn't really fit for
fonts or CSS frameworks like bootstrap and the like.  It's a fairly common term
for this sort of thing in the wild, and emphasizes two important tenets of the
directory: that its contents are shared and static.

> fwiw, i agree that waiting for a new revision of the FHS is implausible.
>  If debian and fedora can agree on something while legitimately thinking
> through and trying to address any potential objections, we shouldn't let
> the FHS's stagnancy stop us.
>
> Thanks for raising this issue, i really do think it would be good to see
> fedora and debian collaborate on this.

-T.C.

[1] https://lists.fedoraproject.org/pipermail/packaging/2013-July/009304.html
[2] https://lists.fedoraproject.org/pipermail/devel/2013-July/185638.html