*** Joins: soustruh (~Miranda@169.211.broadband13.iol.cz) | 02:30 | |
*** Joins: Rixie (~Rixie@188.177.20.182) | 02:38 | |
*** Joins: giallu (~giallu@mail.moldiscovery.com) | 02:45 | |
*** Quits: giallu (~giallu@mail.moldiscovery.com) (Changing host) | 02:45 | |
*** Joins: giallu (~giallu@fedora/giallu) | 02:45 | |
*** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 240 seconds) | 02:55 | |
*** Joins: giallu (~giallu@fedora/giallu) | 03:07 | |
*** Joins: dregad (~dregad@wwwgate1.merck.de) | 03:10 | |
*** Joins: asm89 (~asm89@unaffiliated/asm89) | 03:25 | |
*** Joins: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) | 03:39 | |
*** Quits: asm89 (~asm89@unaffiliated/asm89) (Remote host closed the connection) | 04:34 | |
*** Joins: asm89 (~asm89@unaffiliated/asm89) | 04:39 | |
* dregad pings dhx1 | 05:23 | |
dregad | hi David | 05:23 |
---|---|---|
dregad | back in august I asked you to have a look at some changes to admin checks | 05:24 |
dregad | you replied on mailing list, that I should use htmlspecialchars() to escape values printed to user | 05:26 |
*** Joins: sgimeno (~sgimeno@163.117.206.10) | 05:28 | |
dregad | referring to display of full path in the error message in case of failed check | 05:31 |
dregad | I'm not sure if I should encode the string that is assigned to the info array, | 05:35 |
dregad | or if the string should be escaped by check_print_test_row function | 05:35 |
dregad | which seems more generic, but maybe there are other implications that I'm not aware of | 05:36 |
dregad | what is your advice | 05:37 |
dhx1 | dregad: hey | 05:48 |
dhx1 | dregad: do you have a changeset on github? | 05:49 |
dregad | the code you have already reviewed https://github.com/dregad/mantisbt/tree/improve-checks-13x | 05:51 |
dhx1 | ah yes | 05:52 |
dhx1 | dregad: I'd probably prefer escaping to be done in check_print_info_row() etc functions | 05:53 |
dhx1 | dregad: of course, some of our checks may be sending through HTML characters (italics, etc)... so we'd need to remove that formatting | 05:54 |
dregad | something like this | 05:54 |
dhx1 | hmmm | 05:54 |
dhx1 | maybe not | 05:54 |
dregad | echo '<br /><em>' . htmlspecialchars( $p_info[$p_pass] ) . '</em>'; | 05:54 |
dhx1 | we're placing useful links in those messages | 05:54 |
dhx1 | so it might be best to use htmlspecialchars(...) on a per-check basis when user supplied input is given | 05:55 |
dhx1 | paths, configuration values, etc | 05:55 |
dregad | ok | 05:55 |
dhx1 | I'll probably rewrite admin/check in the next branch anyway | 05:56 |
dregad | should I bother with this fix then ? | 05:56 |
dhx1 | I think so | 05:58 |
dhx1 | given that most of the work is done | 05:58 |
dhx1 | just needs to htmlspecialchar() escaping from what I can see | 05:58 |
dhx1 | https://github.com/dregad/mantisbt/commit/3d4d79e34e38b6c8c13d2e2c0a858b9f0cc4d62b#L0R81 | 05:58 |
dhx1 | and line 83 | 05:58 |
dhx1 | if merging, cherry-pick instead | 05:59 |
dhx1 | of merging | 05:59 |
dhx1 | because that branch will bring in extra stuff we don't want (12x, etc) | 05:59 |
dregad | :-O | 05:59 |
dregad | I know | 05:59 |
dregad | but this code is mostly copy/paste from similar, existing checks | 05:59 |
dregad | nevermind that last comment - before you were always printing a string (the config name) and not the actual config's value | 06:02 |
dhx1 | ok :) | 06:08 |
dregad | dhx1: sanity check please ? | 06:45 |
dregad | https://github.com/dregad/mantisbt/compare/master...improve-checks-13x | 06:45 |
dregad | (note - this is a forced update, 12x is gone - and I'll make this a single commit to Master after) | 06:47 |
dhx1 | looks ok to me | 07:02 |
dhx1 | my only comment is that htmlspecialchars() should ideally be wrapped around each variable | 07:03 |
dhx1 | rather than the whole string | 07:03 |
dhx1 | more of a code readability and maintainability issue | 07:03 |
dhx1 | it makes it more obvious which variables are 'unsafe' | 07:03 |
dregad | ok, I'll fix that | 07:14 |
dregad | done | 07:24 |
dhx1 | :) | 07:28 |
dhx1 | feel free to commit the resulting patch ;) | 07:28 |
dhx1 | I have one I'm going to commit after you | 07:28 |
dregad | actually I meant to keep it for my own benefit only :-P | 07:28 |
dhx1 | haha | 07:31 |
GitHub88 | [mantisbt] dregad pushed 1 new commit to master: http://git.io/X7FhqQ | 07:45 |
GitHub88 | [mantisbt/master] Improve directory validation in admin checks - Damien Regad | 07:45 |
dregad | here you go | 07:45 |
dhx1 | thanks | 07:48 |
dregad | dhx1 - if you get the chance, can you also let me know which is the better branch to fix the attachment indicator issue that we discussed some days ago | 08:12 |
dregad | 1- https://github.com/dregad/mantisbt/commits/fix-attach-column-13276 | 08:13 |
dregad | 2- https://github.com/dregad/mantisbt/commits/remove-show_attachment_indicator | 08:13 |
dregad | I think 2 is better | 08:13 |
dhx1 | dregad: I prefer removing the unwanted configuration value | 08:45 |
dhx1 | however I'm not sure whether we can merge attachment/attachment_count... still have to look into it | 08:45 |
dregad | i did not find any diverging uses, nor issues in my testing | 08:47 |
dregad | let me know if you think otherwise | 08:48 |
dhx1 | ok, will try to get onto it tomorrow | 08:56 |
dhx1 | sorry about the delay | 08:56 |
dhx1 | have been spending all my MantisBT time on the 'next' branch | 08:56 |
dregad | no worries | 08:56 |
dregad | I'm trying to clean up my backlog | 08:56 |
dregad | new responsibilities coming up, so likely to have less time to spend on Mantis at work :( | 08:57 |
dhx1 | ah :( | 09:03 |
dhx1 | thanks for all your help recently | 09:03 |
dhx1 | I'll try to help with the backlog | 09:04 |
dregad | i'll still be around don't worry | 09:15 |
dhx1 | good to hear :) | 09:15 |
GitHub140 | [mantisbt] davidhicks pushed 20 new commits to next: http://git.io/iZxj2g | 09:15 |
GitHub140 | [mantisbt/next] Implement IssueReadOnly exception - David Hicks | 09:15 |
GitHub140 | [mantisbt/next] Implement RelationshipNotFound exception - David Hicks | 09:15 |
GitHub140 | [mantisbt/next] Implement RelationshipLoopbackDisallowed exception - David Hicks | 09:15 |
dhx1 | almost finished replacing the old error system... just a few exceptions to go | 09:16 |
dhx1 | then some rework of the error handler | 09:16 |
dhx1 | next up: focus on Paul's database work (a lot to do) | 09:17 |
dhx1 | after those items I'd like to merge next into master (after extensive testing) | 09:17 |
dhx1 | and then continue with some other project(s) with MantisBT (mostly code modernisation to OO) | 09:18 |
*** Joins: paul___ (52c6fa08@gateway/web/freenode/ip.82.198.250.8) | 09:25 | |
dhx1 | paul___: hi *waves* | 09:26 |
GitHub189 | [mantisbt] davidhicks pushed 1 new commit to next: http://git.io/uIYtCQ | 09:26 |
GitHub189 | [mantisbt/next] Use correct error constants in CustomField* exceptions - David Hicks | 09:26 |
*** Joins: JonMarkGo (~Jon@ool-18bfe16f.dyn.optonline.net) | 09:33 | |
jreese | dhx1: you've been busy :P | 09:33 |
dhx1 | jreese: :) | 09:34 |
dhx1 | jreese: they're all small commits though | 09:36 |
dhx1 | (which makes it easy to revert anything that's wrong) | 09:37 |
jreese | yeah | 09:38 |
dhx1 | jreese: while you're here, I was wondering why we went with phputf8 over PHP's built in mbstring support? | 09:41 |
dhx1 | jreese: was it purely a case of mbstring not being in standard PHP installations prior to PHP 5.2 or 5.3 or whatever? | 09:41 |
jreese | because the mbstring module isn't guaranteed to be available, so we fall back to phputf8 when mbstring isn't installed | 09:41 |
dhx1 | oh my mistake, it's still not a standard (built-in) extension | 09:42 |
dhx1 | I thought they'd added it to PHP 5.3 | 09:42 |
jreese | I don't know why they've haven't made it part of the core build, it's pretty dumb imo | 09:43 |
dhx1 | probably because PHP6 with it's superhero UTF8 abilities was always just around the corner? ;) | 09:44 |
jreese | lol, right | 09:44 |
jreese | seems PHP6 == Perl6 these days | 09:44 |
dhx1 | they gave up AFAIK... and are working on incremental 5.x series updates | 09:44 |
dhx1 | the good news is that they're finally switching to git! | 09:44 |
jreese | yeah, except they're still munging it to work with their stupid development workflow | 09:45 |
dhx1 | the bad news... it's still PHP... I'd love type safety, function overloading, etc... | 09:45 |
dhx1 | hah | 09:45 |
jreese | dhx1: it already has type safety of function arguments if you want it | 09:45 |
jreese | granted, it's not used by any of teh core APIs, but it is available | 09:46 |
dhx1 | jreese: yeah it's got some limited support here and there | 09:46 |
* dhx1 wonders why people don't just use C++ (a simple version) with a library that does FastCGI, etc handling | 09:47 | |
dhx1 | other than no compilation needed for development work... | 09:48 |
jreese | setting up fastcgi is th esort of effort that makes PHP so simple to deploy by comparison | 09:48 |
jreese | and PHP's built-in templating system (ie, <?php ?>) is its biggest feature | 09:49 |
jreese | and it's core library is already familiar to anyone who knows C or Perl | 09:49 |
dhx1 | although it's funny that many PHP users try to avoid that feature by using overly complex data model abstractions | 09:50 |
jreese | not that I think PHP is a good language | 09:50 |
dhx1 | the only thing I like is the preg_ functions ;) | 09:50 |
jreese | but deploying PHP is fantastically easy with apache/mod_php | 09:50 |
jreese | either way, I've gotten to teh point where I won't personally choose PHP for anything I write in the future | 09:51 |
dhx1 | which are standard in C++11 (informal name at the moment): https://secure.wikimedia.org/wikipedia/en/wiki/C%2B%2B11#Regular_expressions | 09:51 |
jreese | all of PHP's warts are more annoying than the deployment hoops of other languages | 09:51 |
dhx1 | mod_php is discouraged anyway | 09:52 |
jreese | dhx1: C++ has always had PCRE | 09:52 |
dhx1 | FastCGI is _the_ way | 09:52 |
dhx1 | jreese: true, but as a separate library (libpcre, Boost, whatever)? | 09:52 |
jreese | it's only the way if you prefer complicated deployment | 09:52 |
dhx1 | distributions have made it fairly easy | 09:53 |
jreese | you can't just drop php files into a webroot and watch it work if you're using fastcgi | 09:53 |
dhx1 | I can? | 09:53 |
jreese | not for any sort of multi-vhost setup, afaik | 09:53 |
dhx1 | unless I misunderstood | 09:53 |
jreese | the moment you want more than one vhost, your fastcgi setup starts ballooning in complexity | 09:54 |
dhx1 | you should still be able to do that... but you'd probably need to run multiple pools of FastCGI daemons under a different user account for each website | 09:54 |
jreese | yes, that's my point | 09:54 |
dhx1 | yeah | 09:54 |
dhx1 | in the days of virtual private servers though, shared hosting is less common | 09:54 |
jreese | I run 12 different vhosts on my vps, I don't want to run 8 different fastcgi pools | 09:55 |
dhx1 | you don't have to... it's more of a security/separation issue | 09:55 |
dhx1 | so websites can't access each other on the disk | 09:55 |
jreese | esp when mod_php requires zero configuration, and APC basically makes it fast enough that fastcgi doesn't make that big of a difference | 09:56 |
jreese | also, tbh, I get better memory performance from apache/mod_php than apache/fastcgi | 09:57 |
*** Parts: Rixie (~Rixie@188.177.20.182) () | 09:58 | |
dhx1 | the main reason mod_php is discouraged (AFAIK) is for the same benefit you mentioned - shared memory | 09:59 |
dhx1 | again I think it is mostly from a security perspective... shared memory = shared PRNG, ability for all your sites to come to a crashing halt at once, etc | 09:59 |
jreese | well, using multiprocess apache, one crash doesn't bring down the whole apache instance, and shared prng is the least of my worries tbh | 10:00 |
dhx1 | yeah | 10:00 |
jreese | my point is just that I don't want to spend hours setting up and maintaining nginx/fastcgi setups when apache/mod_php does it all by default, and imo performs just as well | 10:02 |
jreese | maybe if I was paid to set up and maintain webservers, I'd think differently | 10:02 |
dhx1 | yep | 10:02 |
jreese | modwsgi is easier to deal with than fastcgi, and it still has a lot of pain points | 10:03 |
jreese | like needing to touch the .wsgi file to get the webserver to reload the instance when I make changes in development | 10:04 |
jreese | I was actually tempted to write a script that would just sit around in a webroot looking for changes to .py file so that it could automatically touch the .wsgi file | 10:05 |
dhx1 | hah, it must use caching | 10:09 |
dhx1 | should be able to turn that off so that each reload hits the disk? | 10:09 |
jreese | it's not caching | 10:09 |
jreese | it has to do with the way python/ruby types of systems work; when modwsgi loads the app, it compiles everything and starts a long-running process that waits for the webserver to proxy requests to it | 10:10 |
jreese | so by default, that wsgi container never restarts until the server restart | 10:11 |
jreese | at least in modwsgi, the only option is to have it restart when the .wsgi file is touched, because it can't know if any of the other files are touched, because wsgi doesn't force the .py files be anywhere that the server knows about | 10:12 |
jreese | and it seems to be that way on every wsgi module/container, even with nginx | 10:12 |
dhx1 | aha | 10:12 |
jreese | ideally, during development, modwsgi would start up the container on each request, and then immediately stop it, but that would be a lot of work in cases where web apps use a lot of ajax or other sorts of constant interaction | 10:14 |
jreese | so the best they can really do is watch tho .wsgi file for changes to know when to reload the container | 10:14 |
jreese | long-polling message systems like comet, etc would provide even more issues with that sort of approach | 10:15 |
dhx1 | hmm, messy ;) | 10:15 |
jreese | the real problem is developing on a server that's also a production box :P | 10:15 |
dhx1 | if they're running on a Linux system they should at least use inotify to monitor files on the disk for changes | 10:16 |
*** Quits: soustruh (~Miranda@169.211.broadband13.iol.cz) (Quit: visit http://wormscesky.cz) | 10:16 | |
jreese | when testing on a local dev machine, you generally use a purpose-bulit development server/container like paste or cherrypy, but then you may have to deal with differences between your development and deployment envirnoments | 10:16 |
jreese | dhx1: but like I said, the web server has no way to know what files are being used by the container, because it's basically running an externel python interpreter to run the webapp | 10:17 |
jreese | and an `import foo` in python can pull files from just about anywhere depending on where modules are installed, your python's PATH environment, etc | 10:18 |
jreese | the only way the server can know what files are being used is if it implements a python interpreter itself to parse all the files :P | 10:19 |
dhx1 | hmm | 10:19 |
jreese | complicated systems are complicated :P | 10:19 |
dhx1 | :) | 10:20 |
dhx1 | on that note, I'm out | 10:20 |
dhx1 | will be around later to finish off the work on error handling in the 'next' branch | 10:20 |
jreese | cheers | 10:20 |
dhx1 | until later | 10:20 |
dhx1 | cya | 10:20 |
*** Quits: paul___ (52c6fa08@gateway/web/freenode/ip.82.198.250.8) (Quit: Page closed) | 10:21 | |
*** Joins: T-One (~T-One@213.33.91.2) | 10:22 | |
T-One | hello | 10:22 |
T-One | small prolbem here, i've copied a mantis 1.1 with all the config files and attachments + sqldb to a new server, it looks like mantis works quite well but all the attachments are just given as (attachment missing) | 10:24 |
jreese | T-One: if you changed filesystem paths, you will need to manually update your database's attachment table to fix the paths it has stored | 10:24 |
T-One | i didnt change the file path, its given as " $g_absolute_path_default_upload_folder = 'upload/';" in the config and i can access this path directly via http://<ip>/upload | 10:26 |
T-One | in the mysql-db all those files are listed in the mantis_bug_file_table with values like "upload/29ffc78295273f9426ecf1f541c46ac1" | 10:27 |
jreese | T-One: I'm not sure offhand, I just know that that moving mantis aronud can cause it to be looking in the wrong place for attachments on disk =\ | 10:30 |
jreese | sorry | 10:30 |
T-One | could it be a permission problem too? | 10:34 |
jreese | possibly, the webserver account will need read access to the files | 10:34 |
jreese | or whatever account the php files are executed as | 10:34 |
T-One | ah ok, just read access, thats given.... | 10:35 |
*** Quits: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) (Remote host closed the connection) | 10:42 | |
*** Quits: asm89 (~asm89@unaffiliated/asm89) (Quit: bye!) | 11:16 | |
T-One | could someone please check the layout of their diskfile part in the bug_file_table | 11:26 |
T-One | mine are given this way: upload/beide\dman\ab8225bb66586f8c8bfa7f542b5ad159 | 11:26 |
T-One | and i think thats not correct | 11:26 |
T-One | they should be saved as upload/beide/dman/ab8xxxxx | 11:26 |
T-One | yep got it, file paths are incorrect | 11:29 |
T-One | because the first install is from a windwos apache server, and then migrated to linux.... | 11:30 |
dregad | jreese: hi | 12:14 |
dregad | do you have any idea why, in 1.3.x, I get "XML Parsing Error: not well-formed", whenever an error occurs (looks like there is an extra </div> at the end) | 12:16 |
dregad | Note- I have E_USER_ERROR => 'halt' (no problem if I set it to 'inline') | 12:21 |
*** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 260 seconds) | 12:42 | |
*** Quits: siebrand (~siebrand@5353A6DC.cm-6-4c.dynamic.ziggo.nl) (Quit: siebrand) | 13:12 | |
*** Joins: siebrand (~siebrand@5353A6DC.cm-6-4c.dynamic.ziggo.nl) | 13:13 | |
*** Joins: kirillka (~Miranda@37-224-55-95.baltnet.ru) | 13:33 | |
jreese | dregad: because dhx thought it was a good idea to use a strict XHTML doctype, even though I urged him otherwise :P | 13:47 |
*** Quits: DarkStar851 (~DarkStar8@142.163.169.117) (Read error: Connection reset by peer) | 14:15 | |
*** Joins: DarkStar851 (~DarkStar8@142.163.169.117) | 14:15 | |
*** Joins: Paul24 (~IceChat09@2001:470:9310:aaaa:f5bf:62c:1767:fa95) | 14:21 | |
*** Joins: giallu (~giallu@fedora/giallu) | 14:27 | |
*** Joins: cgraefe (5f75d16b@gateway/web/freenode/ip.95.117.209.107) | 14:52 | |
*** Quits: wolog (~wolog@wolog.info) (*.net *.split) | 15:24 | |
*** Quits: brucelee (~adsfasdf@c-67-160-201-8.hsd1.ca.comcast.net) (*.net *.split) | 15:24 | |
*** Quits: PennStater (~Aaron@unaffiliated/pennstater) (*.net *.split) | 15:24 | |
*** Joins: brucelee (~adsfasdf@c-67-160-201-8.hsd1.ca.comcast.net) | 15:24 | |
*** Joins: PennStater (~Aaron@unaffiliated/pennstater) | 15:25 | |
*** Quits: PennStater (~Aaron@unaffiliated/pennstater) (Excess Flood) | 15:25 | |
*** Joins: PennStater (~Aaron@unaffiliated/pennstater) | 15:25 | |
*** Quits: PennStater (~Aaron@unaffiliated/pennstater) (Excess Flood) | 15:25 | |
*** Joins: PennStater (~Aaron@unaffiliated/pennstater) | 15:26 | |
*** Quits: PennStater (~Aaron@unaffiliated/pennstater) (Excess Flood) | 15:26 | |
*** Joins: PennStater (~Aaron@unaffiliated/pennstater) | 15:27 | |
*** Quits: PennStater (~Aaron@unaffiliated/pennstater) (Excess Flood) | 15:27 | |
*** Joins: PennStater (~Aaron@unaffiliated/pennstater) | 15:27 | |
*** Quits: PennStater (~Aaron@unaffiliated/pennstater) (Excess Flood) | 15:27 | |
*** Joins: wolog (~wolog@wolog.info) | 15:30 | |
*** Joins: PennStater (~Aaron@unaffiliated/pennstater) | 15:34 | |
*** Joins: soustruh (~Miranda@ip-86-49-121-75.net.upcbroadband.cz) | 16:08 | |
*** Joins: asm89 (~asm89@unaffiliated/asm89) | 16:32 | |
*** Joins: polariw (~polariw@50-73-189-218-pennsylvania.hfc.comcastbusiness.net) | 16:37 | |
*** Quits: polariw (~polariw@50-73-189-218-pennsylvania.hfc.comcastbusiness.net) (Quit: Leaving) | 16:46 | |
Paul24 | mo | 17:04 |
*** Quits: asm89 (~asm89@unaffiliated/asm89) (Quit: bye!) | 17:20 | |
*** Joins: Ragnor (~Ragnor@dslb-092-072-244-211.pools.arcor-ip.net) | 17:40 | |
*** Quits: soustruh (~Miranda@ip-86-49-121-75.net.upcbroadband.cz) (Quit: visit http://wormscesky.cz) | 18:20 | |
*** Quits: Paul24 (~IceChat09@2001:470:9310:aaaa:f5bf:62c:1767:fa95) (Quit: Clap on! , Clap off! Clap@#&$NO CARRIER) | 18:25 | |
*** Quits: cgraefe (5f75d16b@gateway/web/freenode/ip.95.117.209.107) (Ping timeout: 252 seconds) | 18:38 | |
*** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 260 seconds) | 19:12 | |
*** Quits: scribe9343423 (~scribe934@static.96.23.63.178.clients.your-server.de) (Remote host closed the connection) | 20:00 | |
*** Joins: scribe9343423 (~scribe934@static.96.23.63.178.clients.your-server.de) | 20:00 | |
*** Joins: ComputerNewbie (~adsfasdf@c-67-160-201-8.hsd1.ca.comcast.net) | 21:22 | |
*** Quits: brucelee (~adsfasdf@c-67-160-201-8.hsd1.ca.comcast.net) (Ping timeout: 260 seconds) | 21:25 | |
*** Quits: kirillka (~Miranda@37-224-55-95.baltnet.ru) (Read error: Connection reset by peer) | 21:36 | |
*** Joins: kirillka (~Miranda@37-224-55-95.baltnet.ru) | 21:36 | |
*** Joins: ToffeePops (~chatzilla@202.20.3.13) | 22:41 | |
*** Quits: JonMarkGo (~Jon@ool-18bfe16f.dyn.optonline.net) (Ping timeout: 250 seconds) | 23:51 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!