Release Meeting: 05 Mar 2018

Details

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

IRC Log

(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/INCLUDE.pm did not have the changes.
(09:28:50 AM) gac410: No idea how that happened. Git log on lib/Foswiki/Macros/INCLUDE.pm 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, https://foswiki.org/WebLeftBar ... (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 foswiki.org/WebLeftBar.
(10:00:26 AM) gac410: My nginx based sites have same behavior. site.com/topic resolves to the topic.
(10:00:47 AM) MichaelDaum: umpf
(10:01:42 AM) gac410: Same URL on https://trunk.foswiki.org/WebLeftBar 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 foswiki.org/TopicName 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: site.com/TopicName (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 https://foswiki.org/Development/FallBackToTopicWhenTrailingSpaceAndNoSuchSubweb 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 foswiki.pm, 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
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