Session Start: Mon Sep 10 21:54:40 2007 Session Ident: #twiki_release [21:54] * Now talking in #twiki_release [21:57] * SteffenPoulsen has joined #twiki_release [22:03] * Zenopus has joined #twiki_release - [22:03] Zenopus is i=nat18260@xenoc.demon.co.uk * Zenopus [22:03] Zenopus on #twiki_release #oracle #centos +#apachefriends #jboss #wikipedia-da #eclipse #twiki [22:03] Zenopus using irc.freenode.net http://freenode.net/ [22:03] Zenopus is away: try later [22:03] Zenopus End of /WHOIS list. - [22:03] * ArthurClemens has joined #twiki_release [22:04] Meeting is just about to start [22:04] seems the wysiwyg meeting doesn't want to end [22:05] yep [22:05] Let us give them a few minutes to end. [22:05] I'm finished [22:05] just waiting for the ripples to spread [22:05] hi all [22:05] http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x09x10 [22:05] hi peter [22:06] we're done [22:06] at twiki_editor [22:06] nice, the ntp project also uses twiki [22:06] * DavidAllen has joined #twiki_release [22:06] hi arthur, carlo, crawford, gilmar, koen, kwang, kenneth, steffen, sven, will, zenopus [22:06] and dave [22:06] i'll be mostly lurking... [22:07] good turnout today [22:07] Zenopus: could you please introduce yourself? [22:07] wbniv: here in person? [22:07] who is facilitating, who is taking notes? [22:07] I am on the notes already [22:08] thanks kenneth [22:08] i can facilitate unless someone would like to [22:08] PeterThoeny: go ahead, bit tired today so i'm going to pass [22:09] ok [22:09] ---+ action item review [22:09] thanks! [22:09] many bugs items closed :-) [22:09] two open [22:09] Two beta blockers open yes. [22:09] Item4048: EditTablePlugin: Password in URL params after template login [22:09] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4048 [22:09] has anyone succeeded in reproducing 4048? [22:10] That one several of us cannot reproduce. [22:10] and Item4523: You can add all sorts of scripting via URL and get it shown on any topic with URLPARAM [22:10] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4523 [22:10] It must require some special setting to create that scene [22:10] what i intend to do is look closely at the code involved, to see if there is a potential problem somewhere [22:10] (speaking on 4048) [22:10] thanks koen! [22:11] We need Rafael who is also the original reporter to explain exactly how to reproduce. I have emailed him. [22:11] last time I talked to him he couldn;t reproduce it either :-( [22:11] I have the feeling it is either a misconfiguration - or it has been fixed. [22:11] but let's set it waiting for feedback from Raf [22:11] high level fix for 4048 is simple: remove all login/pword from url parameters [22:12] Lavr: could you forward to me if you get a reply (or add to the bugreport)? [22:12] gmc yes [22:12] PeterThoeny: yes, i think we can do that anyway [22:12] login / pass is not passed in URL parameters, AFAIK [22:12] afaic it is alread coded that way [22:12] the few times they are required they are passed using passthru files [22:12] but there seems to be a corner case [22:12] so never leave the server [22:13] ok.. well we'll have to wait for rafael to pass us some more details [22:13] * CDot wodners if passthru might be disabled somehow? [22:13] cdot: any pointers as to where i might look? [22:13] gmc: if I knew that..... [22:13] :) [22:13] ok i'll just see what i can dig up.. [22:13] gmc: ask me some awkward q's, we'll work it out [22:13] 4523 is more interesting i think [22:13] I would wait for Raf to explain. In any case I no longer see it as a Beta release blocker. [22:14] Lavr: agreed [22:14] 4523 yes - very interesting and not easy [22:14] the policy we have taken in the past is to disable scripting in public sites [22:14] ok, gmc is on top of 4048 [22:14] now to 4523 [22:14] so I vote we disabled <> when the no-script setting is on [22:14] but allow it otherwise [22:15] Disable scripting - same argument as last time. Not a fix. [22:15] why not? [22:15] too broad [22:15] Because then you also disable scripts entered in topics = cripple TWiki [22:15] we have a choice; we can make TWiki secure for public sites, and cripple it for the enterprise [22:15] or we can cripple it for public sites.... [22:15] and the point is not public versus non public [22:16] the vulnerability is there for non public sites too [22:16] as we discussed before [22:16] As we also discussed last time this is not only public sites that are affected. [22:16] why not? the main use of this hole is phishing, surely? [22:16] Did anyone read the links I added to the bug report [22:16] * gmc did [22:16] the wikiedia article? [22:16] Yes. Plus links from that. [22:17] CDot: if i have a bit of knowledge about the non-public twiki installation behind company X's firewall.. [22:17] Very interesting to see the real cases that have hit [22:17] i can craft an email that has a URL with some Evil Scripting injection in it [22:17] send that to all of company X's employees. [22:17] The best thing would be to - by default encode <, >, and " [22:17] in URLPARAM [22:18] why is that the "best" thing? [22:18] We already have the encoding features in URLPARAM. It is just disabled by default. [22:18] it doesn't block cross-scripting, AFAICT [22:18] CDot: why not? [22:18] If > becomes > etc then you cannot inject anything dangerous [22:19] the problem is that a URL can be used to inject content into a rendered TWiki page, right? [22:19] right [22:19] time check: +20 min [22:19] oh wait; you are talking about *double*-encoding the URL? [22:19] entity encoding *and* URL encoding [22:19] lets spend 5 more min on 4523 [22:20] No. The output from URLPARAM should HTML code > < and " [22:20] Then you are pretty well protected. [22:20] if you do that you make it impossible to pass through parameter values [22:20] The " encoded prevents breaking out of strings. [22:20] so, for example, the login script won;t work [22:20] cdot, you can disable the encoding.. [22:21] but only explicitly so, to make you think 'will this be displayed' [22:22] * CDot is not convinced it buys you any security, but thinks it is a potential source of user problems [22:22] we can't cripple twiki, it is a platform for apps [22:22] Yes. The URLPARAM simply gets an additional encode="raw" [22:22] we should find a way to satisfy the security concerns [22:22] without clippling twiki [22:22] gmc: tell you what, let's implement the encoding and see if we can break it [22:22] I like a challenge [22:22] CDot: sounds like a plan, will also show us what we will break [22:23] s/we will break/breaks/ [22:23] s/clipping/crippling/ [22:23] You can always try twikiapps with the feature already there. Choose URLPARAM{... encode="entity" [22:23] ok, done deal. I will update 4523 accordingly [22:23] this would work but it is not backward compatible [22:23] :-( [22:23] Peter does security mean anything for you? [22:24] yes, i am just asking to think out of the box [22:24] create a patch script of some sort? [22:24] the box being the proposition that the old behaviour is insecure, and that we want to change that.. [22:25] Problem with the current URLPARAM{... encode="entity" is that it encodes too much. And cripples too much. [22:25] clearly, params that core twiki and plugin handle need to be sanity checked [22:25] can someone give an example of what would break if the default for encode will become entity? [22:25] last time I was deeply frustrated about this bug, because our whole platform is open to this stuff .. for instance if you can't directly inject it, you can just save it first .. http://twiki.org/cgi-bin/save/Main/WebHome?text=some_evil_stuff .. and then send the direct url without xss it in your next evil mail [22:26] SteffenPoulsen: assuming you have save access, right [22:26] If we encode < > and " then passwords with those will not work as an example. [22:26] why? the whole point of xss is that people will blindly login at your command [22:27] Lavr: passwords are not displayed, so you can disable encoding on those.. [22:27] Lavr: passwords aren't even handled by URLPARAM, right? [22:27] Yes. In some of our applications there is a URLPARAM used for passwords. [22:28] SteffenPoulsen: you are right, that is an additional problem.. [22:28] You should do a search in the TWiki web for URLPARAM{ and study what we already have. [22:28] Lavr: but the password is not displayed, is it? [22:28] time check: +30 min [22:28] what is the conclusion on 4523? [22:28] No. But if I use a password which is ending the string and start some script then it is executed. I have tried. [22:29] and why wouldn't those passwords work btw, the encoding is consistent.. [22:29] PeterThoeny: i think we haven't reached a conclusion [22:29] PeterThoeny: we are going to implement the encoding and try to break it [22:29] then lets defer that to next time [22:30] i feel we will upset many folks if 4.2 is not backward compatible [22:30] Steffen raises an issue though, in that there are more vectors of attack [22:30] Repeating: Does security mean anything? [22:30] We need to secure against XSS [22:30] repeating: think outside of the box [22:30] to fix the issue [22:31] ---+ 1. Review Urgent Bugs [22:31] Bugs:Item4576 - Too many mail dependencies [22:31] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4576 [22:32] this is best fixed with doc, I thinkm in TWiki.spec [22:32] we just need to inter-relate all the mail controls [22:32] so when you disable/don;t enable email, you know the effects [22:32] Why don't we disable email when no webmaster email address is defined. Why fail? [22:32] because you can still send webnotifies [22:33] No. You need a from address. [22:33] I agree on handling it in configure doc [22:33] You cannot send mails without a from address. [22:33] Lavr: yes you can [22:33] Most webservers will reject it. [22:33] you can;t send them very far, but you can send them [22:34] some mail server will*not* reject them [22:34] you shouldn't send mails without a from address, that's reserved for DSN's.. [22:34] ok, so let's *doc* that fact [22:34] Why not disable emailing when WIKIWEBMASTER is not filled out? [22:34] yes, that sounds sensibel [22:34] PeterThoeny: i'm here now, back from lunch [22:34] * wbniv reading scrollback [22:34] hi will [22:34] i might misunderstand, but it seems you shouldn't be able to enable email verification if you haven't configured email.. [22:35] wbniv: hey Will; lettuce and cottage cheese? [22:35] When you disable verification TWiki will still email the registration done. [22:35] gmc: yes, agreed, but [22:35] the tradeoff if fixing in code, or fixing doc [22:35] the doc is the easy option [22:35] registration should never end in a 500 error [22:35] the code is the better option [22:36] The new admin is drowning in DOC already [22:36] is there any dependency checking going on in configure? ie, checking configuration items that depend on other config items..? [22:36] all it needs is someone to code it [22:36] registration should be an atomic action, with error message(s) shown at the end [22:36] so, anyone the coding skills to fix it can do so [22:37] any owner for code fix? [22:37] but if no-one is available, it may have to be (another) doc fix [22:37] yes [22:37] for 4.2.0 [22:37] put me down for this one then [22:37] very cool, thanks koen! [22:37] # Bugs:Item4511 - Need user-friendly, accessible doc for WYSIWYG [22:38] we talke dabout this in #twiki_editor [22:38] Bugs:Item4522 - IE "Zones" must be documented as a potential WYSIWYG "gotcha" [22:38] aye; pass on [22:38] Carlo took that one right? [22:38] that's in the FAQ for the one-pager [22:38] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4522 [22:38] what about gis one? [22:38] pass on; it;s covered [22:38] ok [22:38] Should go on the one pager right? [22:38] Bugs:Item4506 - (IE only) Copy paste in TinyMCE sometimes makes the page view jump to near the top of the page [22:39] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4506 [22:39] passed on to moxicode [22:39] nothing we can do about it [22:39] What does that help? [22:39] ok [22:39] Bugs:Item4590 - Rename "Checkpoint" to "Save and Continue" - Need to agree on this. [22:39] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4590 [22:39] * CDot doesn;t care; checkpoint is fine [22:39] 4506 STOP [22:40] yes kenneth? [22:40] First of all - I do not see this on my IEs anymore? [22:40] i favor Save and Continue" [22:40] Lavr: I do [22:40] CDot: bbq tofu :-O [22:40] (Save and Continue is more in line with other programs) [22:40] me too [22:40] So what is the reason? [22:40] Lavr: if I knew that.... [22:40] for what? [22:40] "save and contine" is more intuitive [22:40] yes [22:41] problem si we are in string freeze [22:41] I do not buy that moxicode surrender. We have to address this BIG annoyance. [22:41] is it worth cracking the string freeze for this? [22:41] i find that we prematurely declared string freeze [22:42] better to do string freeze two weeks before ga [22:42] It seems noone cares about 4506. [22:42] ok, we're discussing two items at the same time now [22:42] the string freeze was decided last time was at the release of the beta - the beta is not released yet [22:42] because doc work is going on and is safe [22:42] we also need to translate TinyMCE help texts [22:42] Can we finish 4506 please? [22:42] of first 4506 [22:43] Lavr: we never touch modules we inherit - it's just too messy .. but as I state in the topic: If there's a way of tracking bugs vs. code commits in their setup it could perhaps be a way to find inspiration for a solution. [22:43] Have we already approached the moxicode people? [22:43] Do they have a fix checked in we can merge? [22:43] SteffenPoulsen: if we fix it we can always submit upstream, right? [22:43] it _is_ fixed upstream [22:43] oh ok [22:43] so what is the problem then? [22:43] he releases every 3 months or so it seems [22:43] we can always release a plugin update [22:44] So what is the problem merging in a fix then? [22:44] ok, it is fixed, but not released.. [22:44] time check: +45 min [22:44] This bug will make our users run away screaming. [22:44] SteffenPoulsen: are you *sure* it's fixed upstream? I had the impression that he *thought* he had fixed it.... [22:45] CDot: I have no way of checking, you are completely right [22:45] so, someone needs to check.. and if it is fixed, we have to wait for their next release? [22:45] Can someone with Javascript knowledge approach the guys? [22:46] Lavr: if you want to find the diff he did and apply it to our SVN for my sake no problem, just clear it with others that might have an objection [22:46] is it the case that the release of tmce we have now must be the one that is in 4.2 release? [22:46] no, not necessailry [22:46] I prefer to release only unpatched 3rd party suff [22:46] but if a patch has to be applied, so be it [22:46] absolutely [22:46] ehrmz.. [22:47] absolutely on the unpatched remark that is [22:47] so consensus is to apply patch if available? [22:47] for this one case? [22:47] Lavr: track it down and tell us how big a deal it is - probably it will make sense [22:47] First find out if it has been fixed. And maybe the guys know a work around. [22:47] or no patch at all? [22:47] i'd say no patch and wait for them to release, but if that is only me.. [22:48] I would stonrlgy prefer not to, but if it;s the only option, and this is a releae blocker.... [22:48] Spocke _tell me_ it has been resolved at http://tinymce.moxiecode.com/punbb/viewtopic.php?id=8433 [22:48] +s [22:48] if there is an ETA on a next release for tmce that coincides with our 4.2 release date.. [22:48] ah, and there's a guy stating it didn't work *g* [22:48] s/coincides/comes before/ [22:49] so much for multi-location tracking :-) [22:49] lets decide: patch or no patch for this one [22:49] kenneth? [22:49] my vote: no patch for beta, patch for release if no tmce release with fix is made [22:49] Steffen if you continue the dialogue with them perheps we can get a fix from them. [22:49] my vote: patch for this one *if and only if it actually works* [22:49] patch [22:49] (assuming it works :/ ) [22:50] Beta is not blocked for this. ONly final release [22:50] I am over my head in work for the next two weeks - no possible way I can find the time I am afraid - would love to [22:50] SteffenPoulsen: I will pick up the torch [22:50] no strong opinion either way / not release blocker for beta [22:51] ok, no release blocker for beta, e.g. no action for beta [22:51] production: if fixed fine, if not no patch [22:51] have you experienced the bug Peter? [22:52] no [22:52] You will be lynched by your users if you release it. [22:52] it can not be in the production release, that's a given i think [22:52] ok, two voices then for patching if needed [22:53] But I still wonder why I do not see it anymore. If there is a browser setting workaround we can put in help then I am OK: [22:53] time check +55 [22:53] And I really have not been able to provoke it for some time now. Strange. I saw it before in 3 different computers. [22:54] Lavr: I just tried on IE, and I can;t reproduce it either [22:54] I will have to read Spocke's code :-( [22:54] * CDot wonders if he has a PHd [22:54] so lets go with original: no release blocker for beta, handle as bug for production (no patch) [22:54] now back to to "save and continue" [22:55] no patch on final release?!? (if needed) [22:55] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4590 [22:55] will: it can't be reproduced now; it might show up again and can be handled as a bug then [22:55] I am for the "save and continue". But we need these words translated from everyone then. [22:56] yes [22:56] hmmm, hate to admit it, but I can't either ... wonder what did this? perhaps the change to match: exact on the textareas? [22:56] and there is more doc work coming up [22:56] Is there doc work with MAKETEXT? [22:56] aside: SteffenPoulsen: the textareas are irrelevant to TMCE (it replaces them with an IFRAME) [22:56] help text for tinymce [22:57] those words should already be translated for every language, btw ... even if we have to paste two previously-translated strings together. i do not think that should be a deciding factor [22:57] aside: I will stop worrying I think :-) [22:57] yes; note that the TMCE plugins contain a lot of strings that do not have translations [22:57] help text is now at: http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4603 [22:57] the bug item that is [22:57] we could help out the TMCE project by feeding those to our translators... [22:57] i do not understand the timing for string freeze [22:58] what was the reason to freeze last week? [22:58] i didn't know we had string freeze already? [22:58] antonio wanted to give time to the translators [22:58] wasn't it some sort of pre-freeze? [22:58] i do not recall we decided a string freeze on last meeting, but a string freeze notice has been sent [22:58] We decided to get the translations started. [22:58] yes [22:59] so a misunderstanding [22:59] so effectively, we do have string freeze, regardless of what has been decided [22:59] terceiro picked up the ball on translations, apparently he decided it was time :-) - general agreement was to freeze at the time of beta [22:59] Well. We need to have a freeze when translators start. And break it in a controlled limited mannor. [22:59] note to myself: send antonio email with note that no in pre-translation and that string freeze is coming up later [22:59] Ie. when needed and not just change to change [23:00] We will NEVER release 4.2.0 if we do not behave like in release mode. [23:00] Lavr: I'm with you on that [23:00] +1 [23:00] yes, agreed [23:00] if checkpoint is the only string, I say "leave it". [23:00] What are those strings that need MAKETEXT changes besides the Save and Continue [23:00] ? [23:00] but small string changes should be ok [23:00] 4.2.1 can fix it. [23:00] no, samll changes are *not* OK [23:01] the knock-on effect is huge [23:01] poor translators [23:01] on 4.0 and 4.1 we had string freeze during one of the rcs, not in beta [23:01] we are simply too early for string freeze [23:01] PeterThoeny: true, but effectively we do have string freeze now [23:01] WHAT are exactly the MAKETEXTs you plan to change? [23:01] there were other changes already, the TWIKIWEB -> SYSTEMWEB happened after string freeze also [23:02] save & contine is one [23:02] there might be more [23:02] time check: +65 [23:02] Yes. and? [23:02] string freeze is at the time of the beta, no need to change that - but we owe translators an apology at the time [23:02] The help one pager for TMCE will be in English only right? [23:02] repeating: TinyMCE help text should be translated [23:03] TMCE help text = one pagers or? [23:04] ok, lets first get an agreement on string freeze timing: [23:04] 1. keep last week string freeze and live with limitations / untranslated text [23:04] 2. lift string freeze, apologize to translators, freeze at rc x [23:04] i am for 2 [23:04] I still need to understand the TMCE help text detail. [23:05] Arthur? [23:05] yes [23:05] the current help text is translated [23:06] so the new text for TinyMCE should be as well [23:06] What help text? [23:06] the new one [23:06] The one pager? [23:06] Carlo will write it [23:06] the TWIKIWEB -> SYSTEMWEB is a big one, impacting many strings, so translators need to fix translations anyway [23:06] yes, a couple of lines [23:07] PeterThoeny: that should be changed in the translation files with find + replace [23:07] The TWIKIWEB / SYSTEM web should be a find/replace exercise. [23:08] so I need to put all text for tmce help into MAKTEXT? [23:08] what do you think on 1 or 2 i asked before? [23:08] (question to all) [23:08] We need to understand the TMCE help scope before we vote [23:08] i have no preference.. thinking about the translators, i'm for 1, thinking about the developers, i'm for 2.. [23:08] Carlo_: yes [23:08] hmmm I don't know enough about the process and the impacts [23:08] kenneth: this is not just tinymce, there is other doc work [23:09] 2 (we usually allow for two weeks of translation time, though) [23:09] yes on two weeks (ga will not be in 2 weeks) [23:09] I do not see an issue going to the translators and ask for a 2nd translation for TMCE which is a new feature. [23:09] there is other doc work, but does it impact MAKETEXT? [23:10] But I would like to keep string freeze on rest [23:11] crawford: if i or other forlsk want to work on doc for usability and we declared string freeze we are impacted [23:11] If the one pager for TMCE help has MAKETEXT then it means the whole text is a MAKETEXT. Isn't that silly? [23:11] we need to give 2 weeks to translators, not 5 or 8 weeks [23:12] The MAIN is getting pretty stable now. I expect a release in 4 weeks. Beta NOW. and RC in 2 weeks. And then release. [23:12] what do other folks vote? [23:12] 1 (except TMCE help) [23:13] Lavr: WikiSyntaxSummary has: * %MAKETEXT{"*bold* put word/phrase in asterisks: =*your phrase*="}% [23:13] 1. keep string freeze [23:13] 2. lift string freeze and freeze at rc [23:13] my vote: 2 [23:13] I vote 2 as well [23:13] * gmc abstains [23:13] 1 (except TMCE help) [23:13] on balance, I think I have to vote (1). It is too late in the dev cycle for major doc rewriting. [23:14] others? [23:14] don't enough about the impacts [23:14] I have to abstain as well [23:14] same [23:14] so it is a tie [23:14] heh; we need an odd number [23:14]