bower security implications

gistfile1.txt

(12:52:26 PM) The topic for #bower is: Bower package manager • http://bower.io • http://bower.io/search/ • https://github.com/bower • Dev meetings Monday 1:00pm PST, 8:00pm UTC
(12:55:20 PM) graste: hi, noobie question perhaps, but I couldn't find something in the docs that answers it:
(12:55:20 PM) graste: when libs in their bower.json specify too much (and don't do 'ignore: "*"' except the dist/min version)
(12:55:20 PM) graste: is it still the opinion to put bower_components in the pub directory?
(12:55:20 PM) graste: I don't want files that are not necessary - especially for security reasons like someone putting a shady-shiny-upload-example.php in their dist directory
(12:55:27 PM) graste: how does bower handle something like that
(12:55:30 PM) graste: does it at all?
(12:56:06 PM) graste: tl;dr: can I ignore in my project's bower.json everything except dist files?
(12:56:56 PM) zecho left the room (quit: Ping timeout: 265 seconds).
(12:57:50 PM) Munter: Why is this a problem? Other than bandwidth wasted when you update?
(12:58:44 PM) graste: I hope you don't do public facing websites
(12:58:54 PM) lnwdr [~lnwdr@195.74.70.239] entered the room.
(12:59:25 PM) Munter: I do. But I don't blindly copy 3rd party stuff when I do a production build
(12:59:29 PM) Munter: And neither should you
(12:59:43 PM) delight [~quassel@bchm-d9bb9c18.pool.mediaways.net] entered the room.
(12:59:55 PM) kaos|work [~ddb@cleversoft-muenchen.vpn-gw.net] entered the room.
(01:00:02 PM) graste: agreed, that's why I ask
(01:00:24 PM) graste: when files are already available as dist versions why should I want to have a build step
(01:01:20 PM) Munter: You should always use uncompressed sources in development in order to be able to debug properly
(01:01:35 PM) Munter: uncompressed and unpackaged
(01:01:37 PM) terinjokes left the room (quit: Ping timeout: 240 seconds).
(01:01:38 PM) graste: I'm not asking for advice on my development process
(01:01:55 PM) Munter: Well, you development process is the cause of your problem
(01:02:19 PM) graste: I'm just asking if there's a possibility to specify in bower.json what I want from deps and what not
(01:03:01 PM) Munter: there is not. This is what your source code is for. Define you dependencies on the parts you need
(01:04:24 PM) terinjokes [~terinjoke@wikinews/Terinjokes] entered the room.
(01:05:53 PM) graste: if that's your answer I can replace bower with a shell  script that does wget calls to github.com/**/*.dist.(js|css) files and get a) more security b) less mitm attack surface via bower c) prolly better performance d) the possibility to skip npm, build steps etc. pp. if I deem that to be a better solution
(01:06:14 PM) Munter: yes
(01:06:17 PM) graste: I see
(01:06:27 PM) graste: now what does bower give me then?
(01:06:33 PM) graste: apart from the search
(01:07:33 PM) Munter: The ability to tag specific versions and a well documented dependency install/update flow
(01:07:39 PM) Munter: Not much more
(01:09:17 PM) Munter: You'll be hard pressed to beat it on performance though. There is some smart async stuff and caching going on. However that is not high on the list of importance either when doing updates
(01:09:27 PM) graste: -.-
(01:09:43 PM) graste: my initial question was with regards to security implications
(01:10:04 PM) graste: performance is not my top priority for development processes that work (tm)
(01:10:40 PM) satazor: graste: if you have 10 deps
(01:10:46 PM) satazor: you don't want to use the 10 dist files
(01:11:02 PM) satazor: you want to organize them in 1 or 2 files, by concatenating them
(01:11:14 PM) satazor: also you may want to do other stuff, like remove console.log's
(01:11:15 PM) Munter: I handle the weeding out of files I don't need by only referring to the files I need in developemnt. My production build step only includes files I refer to in development
(01:11:24 PM) satazor: translate URLs to static server, apply cache busting
(01:11:28 PM) satazor: so many things..
(01:11:46 PM) graste: you don't follow me here, I guess
(01:12:03 PM) graste: I have build steps and stuff and know how to compartmentalize my files in whatever structures and modules I want
(01:12:07 PM) graste: that was not my question
(01:12:17 PM) Munter: So what was. I clearly didn't understand
(01:12:54 PM) m0nkmaster [~m0nkmaste@host86-128-100-153.range86-128.btcentralplus.com] entered the room.
(01:13:29 PM) graste: imho people that blindly follow "the bower way" (tm) of installing packages by name (and version)
(01:13:29 PM) graste: and putting them into public docroot directories (e.g. "pub/bower_compoents/*")
(01:13:29 PM) graste: have to be aware of the implications of installing files of unknown origin into their pub dirs
(01:13:53 PM) satazor: no one said to put the bower_componetns folder publically available
(01:14:02 PM) satazor: thats why u need a build step, and only deploy the files needed
(01:14:09 PM) graste: perhaps I should do some pull requests with shiny-file-upload-example.(php|rb|js) on some widely known libs of yours to make that issue more apparent to "the community"
(01:14:16 PM) graste: just to prove my case
(01:14:29 PM) graste: I see
(01:15:10 PM) satazor: I use bower in a lot of projects
(01:15:16 PM) intellix left the room (quit: Quit: intellix).
(01:15:25 PM) satazor: many of them are SpoonJS projects, a framework that is used in production in baboom.com
(01:15:30 PM) satazor: but not widely known
(01:15:45 PM) satazor: https://github.com/IndigoUnited/spoonjs-cli/tree/master/plugins/spoon/project_structure
(01:15:49 PM) satazor: check the project structure
(01:15:59 PM) satazor: bower_components go to that folder
(01:16:15 PM) satazor: but only the web/ should be publically available
(01:16:52 PM) satazor: it really depends on the knownledge of people behind the build processes
(01:17:05 PM) satazor: if they are aware of the security implications of having files exposed or not
(01:17:16 PM) satazor: bower does not defined it and its not its job
(01:17:20 PM) satazor: its job is just package management
(01:17:32 PM) graste: *I* know how to do that, the question is, if frontend developers are aware of such implications when they use bower for e.g. smaller, more static projects or whatever
(01:17:37 PM) satazor: what you do with the files it downloads, it's your choice
(01:17:56 PM) satazor: I guess most of them do not
(01:18:01 PM) graste: that *you* do know what to do is just not relevant when frontend devs use bower
(01:18:01 PM) graste: to just do quick projects without first starting a whole new frontend build process using grunt or whatever build tool is en vogue at that moment in time
(01:18:15 PM) satazor: most frontend people don't have that knowledge
(01:18:27 PM) graste: not everyone has build tool chains and stuff just for minimizing a file that is available minified etc. anyways
(01:18:29 PM) graste: via bower
(01:18:47 PM) graste: problem is, that there *might* be shady files next to that dist file
(01:18:51 PM) graste: after bower install
(01:19:12 PM) graste: and I know you guys won't be able to solve such a problem automatically via algorithms
(01:19:24 PM) graste: but I'm asking what your approach as a package manager ist about that level of trust
(01:19:27 PM) graste: people give you
(01:19:46 PM) graste: -t
(01:20:15 PM) satazor: yes it's about trust
(01:20:35 PM) satazor: no one stops you from releasing a new version of a npm module with shady stuff
(01:20:47 PM) satazor: and it could do some nasty stuff
(01:20:49 PM) satazor: same as bower
(01:21:05 PM) satazor: but if you do that, your behavior will be accoutned in the community
(01:21:15 PM) satazor: and people will judge you
(01:21:21 PM) graste: yes, but that is probably a backend lib anyways and backend webdevs should be more aware of security implications of random stuff in their pub dirs
(01:21:26 PM) satazor: anyway, you can have a post process install task that could remove files
(01:21:28 PM) lnwdr: satazor: then amybe there should be a warning about this problem for the “inexpereinced frontend people” on the bower hompage?
(01:21:31 PM) graste: frontend webdevs are not
(01:21:58 PM) lnwdr: satazor: as you said yourself: “most frontend people don't have that knowledge”, so better tell them!
(01:22:01 PM) satazor: frontend vulnerabilities can be as severe as backend ones
(01:22:06 PM) satazor: one must not forget that
(01:22:20 PM) satazor: lnwdr: indeed
(01:22:21 PM) Munter: frontend devs should be aware of security concerns
(01:22:32 PM) Munter: Makign them more stupid than they are helps noone
(01:22:48 PM) satazor: Munter: yes, and nowadays it's more important with the proliferation of single page apps
(01:23:04 PM) satazor: frontend applications tend to be more complex
(01:23:18 PM) satazor: nowadays
(01:23:27 PM) graste: frontend devs might not even be aware of the problem of a shady-upload.php in their pub dir - apart form not understanding php or whatever other backend language one uses
(01:23:30 PM) lnwdr: Munter: being inexperienced is not the same as stupidity …
(01:24:53 PM) satazor: graste: indeed, but as I said, bower_components should not be exposed in production
(01:24:58 PM) satazor: perhaps in dev, but not in production
(01:25:05 PM) graste: I know frontend guys that only do css/html for a living and can perhaps put a jquery plugin next to their things, but aren't experienced enough to see security issues that backend devs easily notice
(01:25:30 PM) satazor: for me, it's common sense, but I agree that many people don't think the same
(01:25:33 PM) Munter: Teach them
(01:25:40 PM) graste: satazor: I did not see a single hint somewhere that bower need a deployment chain or toolchain for dev/prod differences
(01:25:59 PM) graste: and btw I can easily use requirejs to have dev and prod versions of files next to each other
(01:26:06 PM) graste: without a backend build step
(01:26:17 PM) satazor: graste: yes README could be improved in that regard
(01:26:38 PM) satazor: anyway the propose of bower is low level package management
(01:27:11 PM) satazor: and bower cannot prevent people of doing all those stupid things
(01:27:45 PM) graste: Munter: it's not about teaching me or me teaching them as I don't maintain or use bower at the moment and I'm seriously not sure at the moment if I event want to use bower if you guys don't have a clear understanding of the security implications of a widely used package manager by a wide variety of people
(01:28:25 PM) graste: imho it's your task to teach users of your software to be a little more aware of implications
(01:28:26 PM) Munter: I do have an understanding of that. It's up to the end user to manage security
(01:28:36 PM) graste: yes, we both have
(01:28:39 PM) graste: that's not the point
(01:28:47 PM) satazor: graste I agree with Munter here
(01:29:05 PM) satazor: when you download stuff to your computer and run them
(01:29:16 PM) satazor: you must be aware of the implications
(01:29:22 PM) satazor: the same is with bower..
(01:29:32 PM) graste: don't derail to wider issues or I will talk about the CA infrastructure
(01:29:36 PM) graste: that is not the point
(01:29:38 PM) satazor: it downloads stuff, if you are concerned you should check what was downloaded
(01:29:44 PM) satazor: and see if the code is malicious
(01:29:58 PM) Munter: You should do that anyway. Name spaces are not reserved in bower
(01:30:08 PM) satazor: and even that, you must setup your project so that it does not expose stuff unnecessarily
(01:30:10 PM) graste: quick question: are you both bower maintainers?
(01:30:25 PM) Munter: I got 'color' because I was fast. Doesn't mean I have the best color library. Or that it even is one, or is safe to use
(01:30:42 PM) satazor: graste: I am one of the maintainers yes
(01:30:43 PM) Munter: I am not a bower maintainer
(01:30:50 PM) graste: ok
(01:32:26 PM) Munter: But I agree, there are a lot of good points to keep a more manual workflow, download external libraries yourself, place in a vendor folder, check them into vcs etc
(01:32:49 PM) graste: so I can take it, that it is the maintainer's attitude to just not make people using their product aware of security implications of simply using it without a build step involved? many frontend guys might never even have heard about the fact that dev/prod build steps are deemed absolutely necessary for bower
(01:32:49 PM) Munter: Also reduces your CI dependency on github, bower and network being up
(01:32:50 PM) satazor: Munter: that works for small projects yes
(01:33:21 PM) satazor: but for projects like I am used to do, its not very practical
(01:33:59 PM) satazor: graste you are advisable to build your projects, but not required to
(01:34:10 PM) Munter: satazor: I agree. I want the excplicit knowledge that the files in bower_components are not modified by a developer on my end. I want the documentation externally on what version of the libraries are used
(01:34:13 PM) satazor: its up to you, if you care about performance or not
(01:34:35 PM) graste: i'm talking security, not performance...
(01:34:40 PM) satazor: graste I think you are seeing bower as a complete tool
(01:34:41 PM) satazor: it's not
(01:34:45 PM) satazor: its a low level package manager
(01:34:53 PM) satazor: just downloads stuff, ensure versioning, compatibility
(01:34:55 PM) satazor: nothing more
(01:35:02 PM) satazor: it doesn't handle security
(01:35:07 PM) graste: srsly, don't you get what I'm talking about in general
(01:35:25 PM) graste: I know what a package manager is and can do and whatnot 
(01:35:30 PM) Munter: Please convince us why a package manager should handle my websites security
(01:35:56 PM) graste: it should not, but it should make users of their software aware of possible implications
(01:36:05 PM) graste: VERY MUCH AWARE
(01:36:18 PM) satazor: graste what implications? should we mention them all?
(01:36:33 PM) satazor: I mean, I can use bower outside frontend "world"
(01:36:38 PM) satazor: i can use bower to manage java deps
(01:36:39 PM) satazor: or php deps
(01:36:44 PM) satazor: its abstract enough to do that
(01:36:57 PM) satazor: should we make them aware of the implications of those environments too?
(01:38:18 PM) graste: yes, but you guys are maintaining a package manager of *public facing components* in web environments and how I see it for me w/ a php project it's more secure on big projects to just d/l js/css files via composer.json instead of using a dedicated frontend dependencies package manager
(01:38:27 PM) graste: doesn't that sound at least a little weird to you
(01:38:28 PM) graste: ?
(01:38:49 PM) satazor: "package manager of *public facing components*"
(01:38:53 PM) satazor: thats not true
(01:39:04 PM) graste: enlighten me
(01:39:30 PM) lnwdr: Let me give an example: Somoeone hosts a worpress site and starts to build their own themes but is not a professional, experienced dev. they hear about bower and start to use it to track their JS and CSS dependencies. one of the pakcage authors uses a php script in that packages build process. not all of a sudden theres executable PHP code in this wordpress theme. how is that not a problem?
(01:39:31 PM) lnwdr: All of that could me remedied by a simple warnig on the bower website saing: “do not put the packages in your public directories!”
(01:40:20 PM) satazor: as I said, bower just downloads stuff to a folder. If that folder is publicly available, or you trust the code of your components or you have to deal with the consequences.
(01:40:37 PM) satazor: If you want to deal with them, prepare a task to delete or scan those
(01:40:47 PM) satazor: you guys do not see the real problem here
(01:40:51 PM) kayamm [~km@unaffiliated/kayamm] entered the room.
(01:40:54 PM) satazor: the real problem is not those files, is the code itself
(01:41:23 PM) satazor: if the code is malicious you have wider security problem
(01:41:32 PM) satazor: imagine if jquery released a new version with shaddy code inside
(01:41:35 PM) graste: you're still not getting the real problem for inexperienced developers, do you?
(01:41:44 PM) satazor: that would keylog passwords of people
(01:41:49 PM) satazor: and send them to a third party
(01:42:01 PM) satazor: its ur job to check if a jquery upgrade is good enough
(01:42:02 PM) satazor: or not
(01:42:04 PM) graste: in fact satazor I just imagined that before joining this channel to ask what your stance at that is
(01:42:31 PM) satazor: my stance is that you should check the code of third party installed components
(01:42:35 PM) satazor: many of them I don't have too
(01:42:42 PM) satazor: because I trust the developers of that code
(01:42:48 PM) satazor: because I know them in the community
(01:42:53 PM) _Andres [~Andres@94.197.121.240.threembb.co.uk] entered the room.
(01:43:01 PM) satazor: otherwise, I usually give a quick glimpse on it
(01:43:43 PM) satazor: bowers does not audiot peoples code, that would require a lot of resources
(01:43:47 PM) satazor: that bower does not have
(01:44:15 PM) satazor: and even if we do, we would have a more secure package manager but it would cause a lot of impedance
(01:44:20 PM) satazor: in the release cycles of modules
(01:44:23 PM) satazor: that people dislike
(01:44:29 PM) satazor: thats why NPM is not doing it
(01:44:46 PM) _Andres left the room (quit: Read error: Connection reset by peer).
(01:44:59 PM) intellix [~dominic@static.c146-88.i01-5.onvol.net] entered the room.
(01:46:30 PM) satazor: gonna have lunch now
(01:46:34 PM) satazor: will be back later
(01:46:36 PM) graste: what I see is, that you don't care at all for users of your components
(01:46:36 PM) graste: even a security notice to trigger happy webdevs using bower to not import random components  into their projects is too much too ask for obviously
(01:46:36 PM) graste: and even worse: as backend lib package managers don't do "approved packages" (or whatever) you're not even thinking about such a feature for your package manager as well
(01:46:40 PM) shrink0r [~shrink0r@195.74.70.239] entered the room.
(01:46:57 PM) graste: I don't like your stance at this