Re: [Pkg-javascript-devel] [Pkg-fonts-devel] Debian font URLs [was: Re: Debian javascript URLs]

2013-08-22 Thread Paul Wise
Whenever this idea has come up (including the current /javascript
implementation) I have always thought it was a bad idea, especially
for JavaScript. Exposing more than absolutely needed for each website
at minimum is an information leakage. With JS or CSS it might lead to
security issues in the web apps on the same domain. Instead, the
scripts used for setting up vhosts should reference the needed
CSS/JS/etc dependencies using the web server or framework
configuration. In addition, you can never know which URLs a specific
web app, vhost or instance of a web app will use at runtime, so
unilaterally taking over a generic path like /javascript, /assets,
/_assets or /_sysassets is a recipe for annoying our users (social
contract says no).

I also think web fonts (and other recent browser attack-surface bloat)
are an insane idea for security. They also lead to sites doing stupid
things like putting icons into the PUA of web fonts. They are yet
another reason why I'm wishing I could leave the web.

/rant

-- 
bye,
pabs

http://wiki.debian.org/PaulWise

___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel


Re: [Pkg-javascript-devel] [Pkg-fonts-devel] Debian font URLs [was: Re: Debian javascript URLs]

2013-08-22 Thread Jérémy Lal
On 22/08/2013 09:34, Paul Wise wrote:
 Whenever this idea has come up (including the current /javascript
 implementation) I have always thought it was a bad idea, especially
 for JavaScript. Exposing more than absolutely needed for each website
 at minimum is an information leakage. With JS or CSS it might lead to
 security issues in the web apps on the same domain. Instead, the
 scripts used for setting up vhosts should reference the needed
 CSS/JS/etc dependencies using the web server or framework
 configuration. In addition, you can never know which URLs a specific
 web app, vhost or instance of a web app will use at runtime, so
 unilaterally taking over a generic path like /javascript, /assets,
 /_assets or /_sysassets is a recipe for annoying our users (social
 contract says no).

agreed - i don't understand what's the use of sharing all those assets
over http. Besides, it's not that hard to setup a webserver to do just
that and it's up to the user to decide this.

The discussion should be about what are the standard FHS paths to those
files, and if that's not already the case, try to define those paths.
Having standard paths will give us portable httpd configurations.

Another matter is about what are the paths to the other versions of the
files : javascripts or stylesheets can have minified versions, fonts can
have woff, eot, ttf, svg.

Jérémy.



 I also think web fonts (and other recent browser attack-surface bloat)
 are an insane idea for security. They also lead to sites doing stupid
 things like putting icons into the PUA of web fonts. They are yet
 another reason why I'm wishing I could leave the web.
 
 /rant
 

PS: oh come on please don't rant


___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel


Re: [Pkg-javascript-devel] Debian javascript URLs

2013-08-22 Thread Jonas Smedegaard
Quoting Daniel Kahn Gillmor (2013-08-22 05:23:17)
  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.

Please let's discuss those two issues separately.

URL length
--

I did not propose to use /usr/share/javascript (that was only an 
example) but to use whatever is the actual path on each system.

The length of the URL depends on the actual path - and if we 
(coordinated or as single distro) choose to not care about FHS then it 
could indeed be quite short.


panic about exporting /usr
--

I did not mean to imply re-exporting /usr (but can see how that was not 
at all clear from what I wrote - sorry!).

What I meant was to export only the parts we actually need to share, 
just as we do today.

I would want the root path to still be configurable, just as it is 
today, to allow sysadmins to e.g. optionally install a package that 
re-uglifies javascript (either due to some preference in quality of 
uglifier, or add some salt to to work against the host being easily 
identified as a certain release of Debian through fingerprinting).

Trying to not look like generic Debian is a *different* interest of some 
of our users, which clashes with the interest of Debian hosts being able 
to form a CDN (which requires all participating hosts to serve same 
files, and therefore being able to match by patterns).


 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature
___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] HELLO MY GOOD HART

2013-08-22 Thread info info
My name is Miss Sandra damah, female 30 years of a age. I am sending you this 
message believing that you could help me,As a matter of fact, my late father 
was killed recently by the politicians and been the only child, i have given it 
a second thought to re-locate to any were in the world.
Furthermore, i have come to discovered that my late father left up to(9.6m$) 
with 10 kilo grams of gold which is now with one of the Bank  here in Accra 
Ghana.
Your main responsibility is to stand on my behalf with your experience and  
ensure the total evacuation of the funds and the Gold from  where it is secured 
at the moment.

Dear i am counting on you believing that you will give me all your support to 
enable me relocate and after the selling of the gold, you shall assist me 
invest the fund into a profitable business while i forward in my education in 
your country.

Please note that your assistance herein will be of mortal benefit to both of 
us. 

 

 
   

___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel


Re: [Pkg-javascript-devel] Debian javascript URLs

2013-08-22 Thread T.C. Hollingsworth
On Wed, Aug 21, 2013 at 8:23 PM, Daniel Kahn Gillmor
d...@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 

Re: [Pkg-javascript-devel] [Pkg-fonts-devel] Debian font URLs [was: Re: Debian javascript URLs]

2013-08-22 Thread T.C. Hollingsworth
On Thu, Aug 22, 2013 at 12:34 AM, Paul Wise p...@debian.org wrote:
 Whenever this idea has come up (including the current /javascript
 implementation) I have always thought it was a bad idea, especially
 for JavaScript. Exposing more than absolutely needed for each website
 at minimum is an information leakage.

So my reasoning regarding this is similar to Debian's reasoning regarding the
default enablement of daemons.  Debian starts all daemons by default because if
you don't want to run them, you shouldn't install them in the first place. We
enable HTTP access to web assets by default, because if you don't want to use
them, you shouldn't install them in the first place.

 With JS or CSS it might lead to
 security issues in the web apps on the same domain.

This came up in the Fedora discussion too.

There are no cross-origin restrictions on the loading of CSS or JavaScript in
web browser.  If someone can load arbitrary JavaScript or CSS from your server,
they can just as easily load it from a foreign server under their control or
a public CDN.  Even if there were, if someone had already got this level of
control over your application it would offer little in the way of protection,
since attackers could just `eval()` their evil code instead of loading it from
a server.

 Instead, the
 scripts used for setting up vhosts should reference the needed
 CSS/JS/etc dependencies using the web server or framework
 configuration. In addition, you can never know which URLs a specific
 web app, vhost or instance of a web app will use at runtime, so
 unilaterally taking over a generic path like /javascript, /assets,
 /_assets or /_sysassets is a recipe for annoying our users (social
 contract says no).

Sometimes web apps never know that their needed CSS/JS dependencies are either.
Who knows what a Rails app is going to need?

We'd also like to enable new use cases.  Someone might want to create a little
Debian cloud image for running a blog, as a nice free software alternative to
using hosted services.  They might want to include a bunch of themes and fonts
so users can customize it just as easily as they can with the hosted service,
without requiring a bunch of hand-editing configuration files. This makes such a
thing possible.

Right now the cool thing to do is copy-and-paste some HTML from a CDN like
Google's site.  Then all your requests are tracked, you're at the mercy of
a third-party provider, and if they go rouge they can really mess with your
site.  Or they just `wget` the file and it sits un-updated for eternity.

The only way we can compete with this is to make it dead simple for developers
to use. If the instructions for use involve a lot of hand-editing configuration
files and differing instructions for every web server under the sun, people are
just going to keep using CDNs or local copies of these files.

But, if we could have a simple page like [1] or [2], that says just run
`apt-get install libjs-jquery` and add this script tag to your page, then
maybe, just maybe we can improve the web a little bit.

Remember, this is just a default, people who want to customize their setups
still will be able to, and they'll have better standards for doing so.

 I also think web fonts (and other recent browser attack-surface bloat)
 are an insane idea for security. They also lead to sites doing stupid
 things like putting icons into the PUA of web fonts. They are yet
 another reason why I'm wishing I could leave the web.

Previously this was done with either Flash or by using images (which is horrible
for accessibility and generally user-hostile).  Web fonts are a massive
improvement in this area.

-T.C.

[1] https://developers.google.com/speed/libraries/devguide
[2] https://www.google.com/fonts

___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel