Session Start: Sun Sep 02 21:59:36 2007 Session Ident: #twiki_release [21:59] * Now talking in #twiki_release [21:59] brrr tax administration [21:59] hi Lavr_ , arthur! [22:00] hi kenneth [22:00] Good evening [22:00] in the usa we have labor day weekend [22:00] many shops closed [22:01] ArthurClemens: oosh, lucky are the ones that have an accountant for that [22:02] i hate preparing taxes, such a waste in time! [22:02] PeterThoeny: unless you're getting money back [22:02] that is true [22:03] but still, they should never have taken it in the first place then, so still a waste of time :) [22:03] anyway, i've got +5minutes, is everybody here? [22:03] and it should have been sent yesterday... [22:03] yes, lets get started [22:03] I am on the minutes [22:03] lets make this a bit more freeform [22:03] thanks [22:04] http://en.wikipedia.org/wiki/Labor_Day -> "Labor Day marks the beginning of the season for the National Football League and NCAA College Football" .. bad day for football widows -) [22:04] and i can take the facilitation [22:04] http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x09x02 [22:04] excellent, thanks Peter [22:04] quick review [22:04] ---+ Action Item Review [22:04] # Sven to build first beta [22:04] status? [22:05] # Antonio to engage translators [22:05] * MichaelDaum has joined #twiki_release [22:05] # Kenneth to finish release notes [22:05] # Rod to arrange marketing meeting [22:05] this is done [22:05] hi to everybody [22:05] and i just sent out invite for tomorrow [22:05] hi micha! [22:06] sorry for being late [22:06] what is status on sven, antonio, kenneth? [22:06] ping SvenDowideit__ [22:06] I do not know how far Sven is but some of the show stopper that we needed closed are still open [22:06] ah [22:06] I am writing on the release notes right now. [22:07] ok, so he is waiting on bug fixes [22:07] i must apologise for not having looked at 'my' urgent bugs, customer deadlines [22:07] As many may have seen a huge amount of Item have been edited tonight. That is part of the release note work [22:08] great! [22:08] shall we walk through the urgent items? [22:08] gmc: ok, that's it - spanking time :-) no worries, I think it shouldn't stop the beta that there are still some I18N issues [22:08] ---+ 1. Review Urgent Bugs [22:09] from prev meeting, not marked as done: [22:09] # Bugs:Item4048 - Rafael takes a stab at it [22:09] From last week we only had 5 that had to be closed. [22:09] for the beta [22:09] # Bugs:Item4509 - Koen will fix [22:09] will be done end of this week [22:09] # Bugs:Item3652 - Koen likes umlauts [22:09] # plus I18N related items [22:09] yes, i see MichaelDaum has been working on this one too [22:09] good [22:10] kenneth, you have the best overview [22:10] what bugs stop us from releasing the first beta [22:10] ? [22:10] Let me refresh my view for 1 minute [22:10] gmc which one? [22:10] Item3652 [22:11] oh I remember [22:11] oh and RichardDonkin, 3652 has a huge history of discussion [22:11] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3652 [22:11] a client tried to attach some doc to a topic with umlauts in it [22:11] Item4537 is a release blocker which I will close tonight. Extremely simple [22:12] nice [22:12] lots of tinymce issues btw [22:12] Item4534 and Item4535 are two new I opened which I think should be closed. Probably a wrong setup somewhere [22:12] imho we can release a beta with open10 01Item3652 [22:13] 4509 does not prevent beta release [22:13] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4534 [22:13] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4535 [22:13] 4048 is a security bug. We need to close the security bugs [22:13] give me a deadline and 4509 will be fixed, 3652 is a different story though, although it seems it is almost fixed [22:14] imho, only Mr. "Richy - UTF8" Donkin understands what's going on there [22:15] So in my view the beta blockers are 4535, 4534 and 4048. [22:15] on 4048, it says Rafael is working on it.. [22:15] 4535 is a real blocker for beta [22:15] I did not see any work. Anyone else want to look? We just need a hack to remove the username and password from the URL [22:16] i can take 4048, postponing 4509 for a while [22:16] i think we can live with 4534 for beta [22:16] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4048 [22:16] The path that is wrongly used in 4534 and 4535 is the same so they may have the same root cause [22:17] Both link to the edit script [22:17] this is security related, but i do not think it should prevent a beta release [22:17] and what about 4523? although it has been so for a while, it is a XSS [22:17] i would say we can release beta without finsing 4048 [22:17] It is not goof marketing strategy to ignore security [22:17] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4523 [22:18] no, it is not ignoring security, this must be fixed for rc and ga [22:18] but i think broad beta testing early on is important [22:18] On 4523 we also have a security thing to discuss but there it is not clear what is secure and what is not. [22:18] fwiw, i think 4048 should be fixed in the beta [22:19] yes it is emberassing to have a password in a URL [22:19] and ask companies to beta test with that [22:20] ok, i yeld to the consensus: let's fix 4048 before beta [22:20] so, can we have that list of current beta-stoppers again? [22:20] [22:15] So in my view the beta blockers are 4535, 4534 and 4048. [22:21] And we need to discuss 4523 tonight [22:21] +1 on 4523 [22:21] 4535 and 4534 are something Crawford probably can solve quite easily (i hope) [22:21] ok, before we discuss this item, who is on top of 4535, 4534 and 4048, respectiovely? [22:22] 4048 -> me [22:22] seems like [22:22] cool, so we have owners [22:22] The 4535 and 34 are CDot. He has not seen them yet. I have a feeling they have a trivial fix [22:22] lets discuss 4523 [22:23] The problem in 4523 is that we can pass almost anything via the URL to a topic that uses URLPARAM [22:23] the point being that you shouldn't just display what is passed on the url [22:23] If inline scripting is turned off - scripts should be filtered out - and that is the serious part... BUT [22:23] I think that answer as a solution sucks. [22:24] true.. but.. [22:24] this is a fundamental _feature_ of twiki [22:24] it should be possible to add scripts when you have edit rights to a topic - and still block scripts via the URL. [22:24] not sure how we can satisfy the concerns [22:24] the problem is not that you can pass anything as an url param, the problem exists when you just display that without any filtering or checking [22:25] url params and parameterized includes are the building blocks of twiki apps [22:25] if we restrict that we will cripple twiki [22:26] The parameterized include does not go via the URL - right? [22:26] People that have edit rights can add anything anyway. They are not the concern. [22:26] indeed.. just thinking out aloud here, maybe you should be able to wrap URLPARAM input or have some option to URLPARAM that says 'filter this before displaying' [22:26] the only place where you need to watch out if you get a url param and feed it into a plugin variable [22:26] urls can be build by an anonymous user...hitting the site first time. not so with param includes, which have to be editted into a topic. [22:26] that can be handled on the plugin code layer [22:27] I know only two places where we have this problem. The oops code which has been fixed and URLPARAM [22:27] actually, the oops code fix is like to break plugins that depend on it [22:28] url params and posted vars are passed over using this twiki_cache too...to be reused the next turn. [22:28] Then fix the plugins Peter. It totally unacceptable to just take URL input and display it in a topic. [22:28] some input (for instance filenames) have a filter regexp in configure, could probably do ~the same for urlparams (a way for untrusted environments to disable <> and similar) .. and perhaps leave it open per default [22:29] As I can see - filtering > and < out would fix our trouble. [22:29] hm, bette make it secure by default [22:29] i think handling url input is the responsibility of whomever is using URLPARAM.. But URLPARAM should give you the means of filtering out possibly bad content [22:29] what if i do not have control over those plugins? [22:30] ... or twikiapps [22:30] ah, an "untaint" parameter with a regexp for URLPARAM? [22:30] SteffenPoulsen: sounds good [22:30] PeterThoeny: isn't it up to the plugin / twikiapp developer to make sure his handling of arbitrary input is safe? [22:31] or is that expecting too much.. [22:31] * henryjk has joined #twiki_release [22:31] As long as we can find just ONE URLPARAM in our own distributed topics we have a problem. [22:31] And may I remind. http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-2423 [22:31] if we want to keep flexibility that's the strategy we should go for imho [22:31] what if the twikiapp writer is Mr Evil already...prepairing it for the links in his spam emails. [22:31] There is already a CVE filed on another product with exact same problem. [22:31] exactly, taht is up to the plugin code to make sure no bad stuff happens in critical places [22:32] but limiting urlparams in general is too limiting [22:32] Why are we talking plugins here? [22:32] We should be talking URLPARAM. [22:32] THAT is the problem. [22:32] right [22:32] no, again, URLPARAM in itself is not the problem.. [22:32] imho [22:32] i brought it up because the oops fix is likely to break plugins [22:33] So you want to revert the oops fix and leave the oops unsecure also? [22:33] let's go back on urlparam [22:33] (sidenote, is there an item # on the oops fix?) [22:34] I do not have it at hand but yes. [22:35] A simple fix could be to html encode > and < in URLPARAM [22:35] gmc: Item4333 I think [22:35] SteffenPoulsen: tnx [22:35] But that would prevent passing a condition like "date > 20070831" [22:35] we have one security notice there the tabmeplugin shows an image in a tag search page instead of a tag search [22:35] Lavr_: such filtering should be optional [22:36] this can be fixed on the plugin code [22:36] Lavr_: eg. SteffenPoulsen's suggestion of an untaint regexp alike solution [22:36] proper filtering needed where you handle the tag variable [22:36] Lavr_, I think such urlparams are very rare, if they make sense at all [22:36] Peter. That is the URLPARAM thing. it is not Tag related. it is generic [22:36] that is, this bug can be fixed without crippling urlparam [22:37] you could also reverse it, have URLPARAM filter/encode input by default, and have a 'unsafe="on"' parameter to go to unfiltered [22:37] Peter. The TAG security bug is not related to Tag plugin. it is there because there is a URLPARAM in one of its topics [22:38] although that would change URLPARAM's default behaviour, with the potential to break existing code [22:39] Well if I have * Set SOMEVAR = %URLPARAM{Hello}% then I would like SOMEVAR to be able to also be assigned 'x > 7' [22:39] The problem is when it is displayed. [22:39] i disagree, a twikiguest could write %TAGME{ param="bad stuff" }% in a twiki topic, not much different from %TAGME{ param="%URLPARAM{anything}%" }% [22:39] so it is like in perl tainted mode [22:39] allow anything, but do stuff in critical places only after taint check [22:40] in our case, when the plugin handles the param [22:41] Once people can edit they can add funny images anyway. That is not the problem. The problem is when someone links to a commercial TWiki with a URL that injects some porn picture and put the company in a bad light [22:41] Or inject a script that redirects to a phishing site [22:42] protecting against a black hat twikiapp dev is larger than this - for that we probably need an "untrusted env" parameter in configure which completely disallows use of a lot of TML (except for a trusted group) [22:43] sounds good, but how do you distinguish tml by author in a multi-authored env? [22:43] (on save time) [22:43] for this item we should just focus on handling misuse of already-generated html I think [22:43] what if I add a comment to a topic already beeing edited by a trusted user...if I am untrusted I cant [22:44] yep [22:44] yep, lots of sideeffects / loss of flexibility there - but can't offer flexibility in an untrusted env [22:44] wikis are _Very_ vulnerable for bad content. [22:44] time check: +45 min [22:44] We are moving away from URLPARAM again. The problem with URLPARAM is that it displays anything given to it by simple URL. No edit rights needed. No direct access to the TWiki webserver needed. [22:44] lets spend 5 more min on this [22:45] with a decision, or deferred for next time [22:45] Lavr_: that is not a problem with URLPARAM, that is a problem with the usage of URLPARAM in an unsafe way.. [22:45] if no decision [22:45] How will you use URLPARAM in a safe way? [22:45] if you pass it as a condition to something, you are not going to display it.. [22:46] so it can't be used unsafe.. [22:46] there should be an option to use URLPARAM in a safe manner.. so that it prevents scripts or images or whatever being injected [22:46] we have: you get safty if you filter out <, > when expanding URLPARAM, by default, and only the twikiadmin can enable it again. right? [22:46] The simple way could be to html encode < and > with an option to turn it off [22:47] Lavr_: yes, i like that.. [22:47] i agree, it is the responsibility of the plugin authors to check parameters, and the reposibility of page authors for page content [22:47] but doing the filtering by default, again, might introduce some regression issues [22:47] Yes. we just need to give them the possibility to make safe applications [22:48] we give them the possibility to make unsafe applications [22:48] Yes it should encode < and > per default and then you can disable the encoding with a parameter to URLPARAM [22:48] only a higher instance, the twikiadmin, should be able to disable fitlering <,> [22:48] MichaelDaum: i disagree [22:49] it should be just a parameter to the %URLPARAM{}% invocation, so that any app developer can choose unsafe mode [22:49] Why should he be able to do that? What makes you think an average admin will understand what he is doing? [22:49] ``unsafe'' [22:49] i fear we are heading to major incompatibility if we change the default behaviour of urlparam [22:49] PeterThoeny: yes [22:50] Peter, the status quo is allowing XSS, so it seems we need a change. [22:50] PeterThoeny: it is a choice though, default to security while breaking backwards compat, or continue to default to non security and make security optional [22:50] twiki's focus is behind firewall [22:50] agreed, need to keep flexibility as is - almost all of our user base is in trusted envs anyway [22:50] I KNOW we are heading for a new CVE with TWiki if we do not change the behavior of URLPARAM [22:51] for public websites we could add a config setting that does more agressive checks [22:51] You still have not understood the problem I can hear! [22:51] People receive the evil URLS through spam mails. [22:51] could be a start on the "untrusted env" setting that we could use for more purposes later on [22:51] lets keep marketing focus out of security considerations for now, please. [22:52] So you can hit and phish from outside a firewall. That is why there are many CVEs on this type of problem. [22:52] We are not the first with this exact type of problem. [22:52] Lavr_: installations in trusted envs are not hit by this, don't confuse things - only publicly assessible installations are [22:53] ok, solution: make URLPARAM filter by default, have an option to URLPARAM to turn off the filtering.. is that an option? [22:53] phish from outside means the intruder would need to know the url of the internal twiki [22:53] NO. [22:53] SteffenPoulsen: lavr is right, also behind a firewall this works! [22:53] SteffenPoulsen: you send a link to the employees of company X that seems to link to their internal intranet, but includes a script with a fake login page.. [22:53] presto, you've got a lot of passwords from company X users [22:53] ons solution: add a urlparam filter flag to configure [22:53] It does not take much social engineering before you have an email with an internal URL for a twiki site and then you start your attack. it is dead easy [22:54] can we vote on this issue? [22:54] PeterThoeny: that solution is worthless (pardon my french).. when would you turn it off? if you believe no one can send you scary links? [22:55] ok, this needs more research before we can decide [22:55] we have an unusual situation because twiki is an app platform [22:55] i like the solution of filtering by default, have an option to URLPARAM to disable filtering [22:56] Do you have an example where you pass a > or < via URLPARAM? [22:56] and need it to be > instead of > [22:56] yes: show a formatted error text in a twiki page [22:56] I am for gmc's proposal [22:56] internationalized [22:57] anyway, no decision now, lets go to next topic [22:57] (sidenote, i would like to know the actual impact of changing URLPARAM's default behaviour) [22:57] ---+ 2. Coordinate TWiki Release 4.2 [22:57] new beta target date? [22:58] (gmc, low, imho) [22:58] (gmc, high, imho) [22:59] can we shoot for a beta target date? [22:59] beta target date, we had three 'showstoppers', one on my plate, two on cdot's [22:59] gmc: urk, not a good scenario, actually I'm having a hard time to relate to it at all - I wonder how often this happens in real life [23:00] SteffenPoulsen: what happens? [23:00] If we do nothing the reporter will probably raise a CVE against us. And if he does not I will [23:00] the e-mail -> internal website login -> snap passwords stuff [23:01] are we back on XSS via URLPARAM? [23:01] SteffenPoulsen: you underestimate the black hat community i think [23:01] MichaelDaum: i'm afraid so :) [23:01] It happens often enough that Motorola currently have 3 people travelling around the world warning us against it. [23:01] I think so too [23:02] shall we shoot for next weekend for beta build? [23:02] I start to see them triggering the save script, changing pages, making apps etc .. [23:02] Yes. [23:03] I am afraid we can't get away with negative pr via a CVE as a fixed URLPARAM will not be out there soon, people not upgrading easily anyway. [23:03] That was a yes to next weekend. I need to talk to Sven also to see how close he is. I will have release note ready maybe already tomorrow [23:03] PeterThoeny: that is fine with me (4048-wise) but we should check with cdot on the two tinymce issues [23:03] yes, we will discuss wysiwyg tomorrow [23:03] in wysiwyg editor meeting [23:03] Hopefully I can have a short chat with CDot in the morning. [23:04] no real hinderence in anything, as long as they can work "one url at a time" .. I'm kinda stunned if we are to take that threat seriously [23:04] shall we shoot for a code freeze date already? [23:04] i'm going to have to skip that, IRL meeting at that time [23:04] We also need to get the Raw Edit button added. We almost forgot that. [23:04] it would be nice if we could work out a solution to 4523 before the beta though.. [23:04] ah yes, the raw button.. [23:05] yes, that would be ncie to have for beta [23:05] PeterThoeny: essential even [23:05] I added that as a bug item tonight [23:05] gmc, you proposed the right solution. let's vote on it. [23:06] No. Write the solution on the bug item so as many as possible can give their oppinion. [23:06] will do [23:06] There may be a 3rd option not yet discussed. [23:06] Hasty decisions are never good. [23:07] back to dates [23:07] can we shoot for code freeze date? [23:07] too early? [23:08] i would value Kenneth's opinion on that a lot [23:08] as there are two items for cdot and he is not here, we cant make dates, can we [23:08] You mean string freeze - we are on code/feature everything freeze and only fixing bugs [23:09] I assume we branch out TWikiRelease04x02 with the first beta. That is what Sven I agreed a few days ago. [23:09] Lavr_: in that case, we should've have branched [23:09] The first beta will be released FROM the TWikiRelease04x02 [23:09] feature freeze: no more feature work [23:09] code freeze: only urgent bug fixes, no regular bug fixes [23:09] string freeze: no more content changes impacting translations [23:10] anybody got translation statS? [23:10] translations: not started yet i think [23:11] makes it an "unknown" [23:11] we asked antonio to coordinate with the translators [23:11] anything else before we close? [23:11] I have not seen any email sent from Antonio [23:12] (my son is asking me to fix the bicycle so that we can go for a bicycle ride) [23:12] I have no further. [23:13] next release meeting: mon, 10 sep 2007 20:00gmt [23:13] when will the marketing meeting be? [23:13] Item4536 is the bug item with Add the Raw Edit [23:13] MichaelDaum: tomorrow, 20:00 GMT [23:13] yes, please join tomorrow's marketing meeting at 20:00gmt [23:13] ah ok, thanks. [23:14] erm is it tomorrow or the week after? [23:14] PeterThoeny: is this going to be an irc meeting (as in the mail) or are we still into confcall? [23:14] and before that at 19:30gmt we have a short wysiwyg meeting [23:14] yes, the marketing meeting will be interesting :-) [23:14] wysiwyg meeting? [23:14] tomorrow 19:30 wysiwyg, 20:00 marketing, next week mon 20:00 release meeting [23:15] got it [23:15] thanks all! [23:15] last word on URLPARAM solutions: if urls clicked outside the TWiki installation cannot have their referrer-header easily changed, could it be an option to only filter on strange referrers and loosen up on "internal referrers" ... or something .. darn, that scenario buggers me a lot [23:15] thanks for having me again! [23:16] SteffenPoulsen: maybe discuss on #twiki some more? [23:16] Well now the official meeting is over we can brainstorm a little more. [23:16] yep, or the bug item [23:16] * MichaelDaum 's going to bed now [23:16] Good night [23:16] nite [23:16] i'm adding to the bug item currently, and am off to bed too actually.. [23:16] PeterThoeny: have a nice bike ride! [23:16] MichaelDaum: night [23:16] good nite all in europe! [23:17] * MichaelDaum has left #twiki_release [23:17] yep, I'm off to bed as well .. night all