New Foswiki release 2.1.6 is available with important security fixes.
Sourceforge foswiki email lists being discontinued. Subscribe to the new Foswiki announce and discuss lists at MailingLists

Release Meeting: 05 Mar 2018


General status.

Foswiki 2.1.6 was successfully released.

1. Task review

2. Development Discussion

More security discussions with fall out from our CVE release. A couple of decisions were made for upcomging Foswiki 2.2
  • The feature request to create a {HomeWebName} will be expanded to also create a {ConfigWebName}.
  • The ={ConfigWeb} would be added to the top of the template path, providing a template location that cannot be overridden.
  • Any "automatic overrides" that look to them {UsersWebName} will be changed to the new ={ConfigWebName}

3. Next release

Patch release 2.1.6

  • Release from: Release02x01
  • Beta start: (none planned)
  • Release target: 21 Feb 2018

Feature release 2.2.0

  • Feature Freeze: 01 May 2018
  • Release from: master`
  • Beta start: 01 June 2018
  • Release target: 01 July 2018

4. Community Events

Next meeting - - Monday 19 Mar 2018 1300Z — ReleaseMeeting02x02_20180319

Please review and be prepared to discuss FeatureProposals and ReleasePlan


(08:00:37 AM) gac410: good morning all ..
(08:00:59 AM) MichaelDaum_: Hi George
(08:01:00 AM) gac410: Time for a release meeting.
(08:01:02 AM) MichaelDaum_ is now known as MichaelDaum
(08:02:30 AM) MichaelDaum: indeed
(08:02:58 AM) gac410: I only had one small bit of feedback yesterday about 2.1.6 - someone looking for the CVE ... I guess we can make it public today.
(08:03:34 AM) gac410: Though I don't like exposing the "how to" details so soon :(
(08:10:40 AM) gac410: We really do need a better way to save optional site configuration stuff - that cannot be overridden by mere mortals
(08:33:02 AM) gac410: vrurg: ... sorry, we ended up in the FoswikiSecurity channel discussing some of the fallout from 2.1.6
(09:15:47 AM) gac410: Anyway Hi foswiki release.... we got off the rails in the security discussion. Nothing particularly earth shattering discussed that isn't already documented.
(09:16:16 AM) MichaelDaum: lets focus on 2.1.6 and the CVE
(09:17:04 AM) gac410: Okay. Well 2.1.6 is out. And sourceforge is *finally* back online so I can upload 2.1.6 today.
(09:17:26 AM) MichaelDaum: perfect
(09:17:39 AM) gac410: I thnk maybe we shuld hold making CVE public for a few more days until 2.1.6 is announced on sourceforge.
(09:18:08 AM) MichaelDaum: do we refer to the CVE in the rel notes?
(09:18:19 AM) gac410: Rotten timing for them to be offline. Yes. we refer to it.
(09:19:25 AM) gac410: I also need to try to send the 2.1.6 announcement to the SourceForge mailing lists. All my prior attempts bounced due to the server issues at SF
(09:21:13 AM) MichaelDaum: meanwhile I am pushing out all plugins required to update our blog
(09:21:48 AM) gac410: oh good
(09:22:36 AM) gac410: Shall I update your proposal for {HomeWeb} to do a 3-way split? Or start a new proposal.
(09:22:43 AM) MichaelDaum: sure
(09:23:40 AM) gac410: Okay. I'll try to make it phases. 1) split all the variables, 2) Change topics to reference the new variables, and then 3) tackle actually relocating topics.
(09:25:28 AM) gac410: The old VarCachePlugin dies on Wide Print. Was trying to help a site upgrade to 2.1.6 over the weekend.
(09:25:29 AM) vrurg: Hi all!
(09:25:34 AM) gac410: hi vrurg
(09:26:24 AM) gac410: Oh... this reminds me. Somehow master lost a commit
(09:26:40 AM) gac410: and had a regression from Releas02x01. A rather bad one.
(09:26:54 AM) gac410: INCLUDE was busted.
(09:27:55 AM) gac410: Commit e96caf53ad952a3cac9350f7f5108f1c1c4823f2 shows up in the master logs, and is accurate. But the actual file - lib/Foswiki/Macros/ did not have the changes.
(09:28:50 AM) gac410: No idea how that happened. Git log on lib/Foswiki/Macros/ does not have the change listed. It's not that a later commit reverted it, it's just not there.
(09:30:13 AM) MichaelDaum: how did you spot it
(09:33:50 AM) gac410: I was testing the INCLUDE path for the UserRegistration page, and when I went to master, things stopped working.
(09:34:04 AM) gac410: deja-vu as I was sure they were something that had been fixed.
(09:34:20 AM) gac410: Found the task and the commit was just missing. :(
(09:34:59 AM) gac410: Task showed it as applied to master. "git log" showed it. "git branch --contains xxx" showed it, but it was not on the file.
(09:35:31 AM) gac410: All I can think of is somehow a merge failed.
(09:37:13 AM) MichaelDaum: oha
(09:52:44 AM) gac410: Unless we get some more developers, we might want to rethink our marketing: Over 200 polished extensions all actively maintained, to expand the out of the box functions
(09:53:01 AM) gac410: all actively maintained might be a bit of a stretch
(09:53:16 AM) MichaelDaum: ssssh
(09:53:17 AM) gac410: Oh... I found another possible regression. At least a rather unusual behavior.
(09:54:37 AM) gac410: On 1.1.10, ... (note the missing Webname) generates a no such web: WebLeftBar
(09:54:55 AM) gac410: On 2.1.x, it displays Main.WebLeftBar
(09:55:06 AM) gac410: But on master, it's back to the original behavior.
(09:55:28 AM) gac410: I don't ever remember a feature that says the webname can be omitted. Did that slip in somewhere?
(09:56:19 AM) gac410: Or did the Request parser code rewritten for master regress a feature
(09:57:10 AM) gac410: I'm not sure I like the behavior of defaulting the web, if the requested web happens to be a topic in Main.
(09:58:56 AM) MichaelDaum: or is it a glitch in the apache config
(09:59:46 AM) gac410: No I don't think so. It does not redirect, the URL shows
(10:00:26 AM) gac410: My nginx based sites have same behavior. resolves to the topic.
(10:00:47 AM) MichaelDaum: umpf
(10:01:42 AM) gac410: Same URL on generates the expected access denied, no such web.
(10:02:45 AM) gac410: There was so much stuff that went into the old 1.2 catch-all release, back when svn master was a purely playground, it could be an undocumented feature Sven or someone thought was a good idea.
(10:03:42 AM) gac410: Another piece that needs removing is $Foswiki::cfg{FormTypes} Which is a partial Sven feature that was never implemented. Had someone this weekend trying to use it.
(10:05:03 AM) gac410: So the big question before the developers... Is a desired behavior, and we need to grandfather it, feature or not?
(10:06:00 AM) gac410: And... shall we remove the {FormTypes} config definition. It is not referenced in any code, except for a unit test.
(10:07:06 AM) MichaelDaum: yes please
(10:08:03 AM) gac410: I assume yes on remove {FormTypes} What about omitted webname from url?
(10:08:25 AM) gac410: I hate to say it, but I suspect that one will need to stay :(
(10:09:07 AM) gac410: Though it should default to the to be developed Home web.
(10:09:25 AM) MichaelDaum: agreed
(10:11:31 AM) vrurg: I'm currently trying to follow a couple of chats, so could have missed a thing. But why it needs to stay?
(10:12:28 AM) gac410: (omitted web name) I expect has drifted into general use. It's too handy.
(10:13:41 AM) vrurg: Never used it. Possible unpleasant side effects could make it a security issue. I'd get rid of it.
(10:14:14 AM) gac410: This request is in the same area planned for 2.0, but not shown as implemented.
(10:14:59 AM) gac410: My guess is this is a Sven special that got added to 1.2, before we converted from svn to git and our new more conservative master
(10:15:17 AM) gac410: So it's probably been in the code since 2.0. That's a big behavior to just kill off.
(10:16:41 AM) gac410: I have not had any luck doumenting the behavior.
(10:18:06 AM) vrurg: Was it documented? BTW, the proposal is reasonable: there is web in the url and we only need to interpret correctly what is following it. But the case where the path consists of a single element is too controversial,
(10:19:02 AM) vrurg: To my view, reliance on an undocumented feature cannot be considered a good reason for not killing off bad functionality.
(10:19:24 AM) gac410: Deja vu, but I'm sure there is a support or dev request somewhere that eliminates Web specifications for really really short URLs
(10:22:22 AM) vrurg: Google finds nothing. Though I don't have much time to dig too deep.
(10:22:56 AM) gac410: yeah, I'm not finding anything either. It would be a bit of research to try to find out when it was introduced.
(10:22:57 AM) vrurg: Anyway, as it seems that voting is 2:1 against my view, I can't oppose too much. ;)
(10:23:44 AM) gac410: I'll have to see what a change like this does to the rewritten Request parser in 2.2. It's already pretty complicated.
(10:23:53 AM) vrurg: We could postpone the decision and do a little more research.
(10:26:06 AM) gac410: y,
(10:27:21 AM) gac410: That's my take. It may be a /blame /me too. I did do some work on, before the 2.2. rewrite, The "topic=" url param can omit the webname and default to the Userweb. That is documented.
(10:28:32 AM) gac410: Though if I did it, it was completely accidental. but the more I think of it, I can't see how i would have interpreted /Web as /Topic.
(10:29:47 AM) gac410: Nope.... This came in later Foswiki 2.0.0 does NOT default to topic. So I apologize to sven et al.
(10:32:04 AM) gac410: Sorry, I'm wrong. It DOES apply to Foswiki 2.0.0. But it only applies if there is no partial match to be found.
(10:33:06 AM) gac410: er. It only applies if the topic is missing. WebLeftBar was a bad example.
(10:33:21 AM) gac410: jeeze, It only applies if the topic exists.
(10:34:11 AM) gac410: Anyway, this behavior is in Foswiki 2.0.0 so it has been around for a long time.
(10:40:44 AM) vrurg: But you see my point: there are too many interpretations for possible behaviour. None of them is clearly understandable and thus – confusing. Either it has to be documented and made a standard; or killed off. You know my mind about this. ;)
(10:41:21 AM) MichaelDaum is now known as MichaelDaum_
(10:42:17 AM) gac410: It falls onto me. crap. I wrote Foswiki::_parsePath. It grabs the "last component" of a url path ... assuming that all prior components have already been picked up as the web.
(10:42:42 AM) gac410: And then uses that and the trailing / to decide if it might be a webname or if it exists, a topic.
(10:43:45 AM) gac410: So it reduces to... if the only component is the last component, passed through normalizeWebTopicName( $web, $topic) and $web is undefined... it becomes Main.TheTopic
(10:44:10 AM) gac410: So it's an unintended side effect.
(10:44:16 AM) ***gac410 is the goat.
(10:45:19 AM) gac410: And with that ... I need to leave. things to do IRL today. plus I need to upload 2.1.6 to sourceforge and redo the announcements for the hopefully working sourcforge email lists.
(10:46:23 AM) gac410: And the rewrite with 2.2 attempted to be very strict, with unit tests, and fixed the "bug"
(10:49:22 AM) vrurg: Thanks!
(10:49:54 AM) gac410: Anyway, the utility function normalizeWebTopic will always default a webname. while URL parsing does not (in 1.x and 2.2) but does in 2.0 / 2.1
(10:50:52 AM) gac410: Thanks everyone. I'll try to wrap up all the minutes later. and probaby generate a feature proposal. These next two days are busy for me IRL so it may come later in the week
(10:57:08 AM) gac410: I'm going to hijack Foswiki:Development/AddDefaultWebName to split our current USERSWEB variable into 3. USERSWEB HOMEWEB and CONFIGWEB ... default will be current behavior - all identical.
(10:57:55 AM) gac410: We can add to that discussion, a setting to apply HOMEWEB when omitted from the URL, which would make 2.2 compatible with 2.1
(10:59:12 AM) gac410: All user registration would point to USERSWEB as today. Any INCLUDE paths / tailoring would use CONFIGWEB, and the default landing page would be HOMEWEB
(11:00:13 AM) gac410: cu all. Thanks!

Topic revision: r1 - 19 Mar 2018, GeorgeClark - This page was cached on 22 Jun 2018 - 23:04.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy