#foswiki-release 2018-03-05,Mon

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
gac410good morning all .. [13:00]
MichaelDaum_Hi George [13:00]
gac410Time for a release meeting. [13:01]
MichaelDaumindeed [13:02]
gac410I 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.
Though I don't like exposing the "how to" details so soon :(
[13:02]
We really do need a better way to save optional site configuration stuff - that cannot be overridden by mere mortals [13:10]
..... (idle for 23mn)
vrurg: ... sorry, we ended up in the FoswikiSecurity channel discussing some of the fallout from 2.1.6 [13:33]
......... (idle for 42mn)
Anyway Hi foswiki release.... we got off the rails in the security discussion. Nothing particularly earth shattering discussed that isn't already documented. [14:15]
MichaelDaumlets focus on 2.1.6 and the CVE [14:16]
gac410Okay. Well 2.1.6 is out. And sourceforge is *finally* back online so I can upload 2.1.6 today. [14:17]
MichaelDaumperfect [14:17]
gac410I thnk maybe we shuld hold making CVE public for a few more days until 2.1.6 is announced on sourceforge. [14:17]
MichaelDaumdo we refer to the CVE in the rel notes? [14:18]
gac410Rotten timing for them to be offline. Yes. we refer to it.
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
[14:18]
MichaelDaummeanwhile I am pushing out all plugins required to update our blog [14:21]
gac410oh good
Shall I update your proposal for {HomeWeb} to do a 3-way split? Or start a new proposal.
[14:21]
MichaelDaumsure [14:22]
gac410Okay. 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.
The old VarCachePlugin dies on Wide Print. Was trying to help a site upgrade to 2.1.6 over the weekend.
[14:23]
vrurgHi all! [14:25]
gac410hi vrurg
Oh... this reminds me. Somehow master lost a commit
and had a regression from Releas02x01. A rather bad one.
INCLUDE was busted.
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.
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.
[14:25]
MichaelDaumhow did you spot it [14:30]
gac410I was testing the INCLUDE path for the UserRegistration page, and when I went to master, things stopped working.
deja-vu as I was sure they were something that had been fixed.
Found the task and the commit was just missing. :(
Task showed it as applied to master. "git log" showed it. "git branch --contains xxx" showed it, but it was not on the file.
All I can think of is somehow a merge failed.
[14:33]
MichaelDaumoha [14:37]
.... (idle for 15mn)
gac410Unless 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
all actively maintained might be a bit of a stretch
[14:52]
MichaelDaumssssh [14:53]
gac410Oh... I found another possible regression. At least a rather unusual behavior.
On 1.1.10, https://foswiki.org/WebLeftBar ... (note the missing Webname) generates a no such web: WebLeftBar
On 2.1.x, it displays Main.WebLeftBar
But on master, it's back to the original behavior.
I don't ever remember a feature that says the webname can be omitted. Did that slip in somewhere?
Or did the Request parser code rewritten for master regress a feature
I'm not sure I like the behavior of defaulting the web, if the requested web happens to be a topic in Main.
[14:53]
MichaelDaumor is it a glitch in the apache config [14:58]
gac410No I don't think so. It does not redirect, the URL shows foswiki.org/WebLeftBar.
My nginx based sites have same behavior. site.com/topic resolves to the topic.
[14:59]
MichaelDaumumpf [15:00]
gac410Same URL on https://trunk.foswiki.org/WebLeftBar generates the expected access denied, no such web.
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.
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.
So the big question before the developers... Is foswiki.org/TopicName a desired behavior, and we need to grandfather it, feature or not?
And... shall we remove the {FormTypes} config definition. It is not referenced in any code, except for a unit test.
[15:01]
MichaelDaumyes please [15:07]
gac410I assume yes on remove {FormTypes} What about omitted webname from url?
I hate to say it, but I suspect that one will need to stay :(
Though it should default to the to be developed Home web.
[15:08]
MichaelDaumagreed [15:09]
vrurgI'm currently trying to follow a couple of chats, so could have missed a thing. But why it needs to stay? [15:11]
gac410site.com/TopicName (omitted web name) I expect has drifted into general use. It's too handy. [15:12]
vrurgNever used it. Possible unpleasant side effects could make it a security issue. I'd get rid of it. [15:13]
gac410This request https://foswiki.org/Development/FallBackToTopicWhenTrailingSpaceAndNoSuchSubweb is in the same area planned for 2.0, but not shown as implemented.
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
So it's probably been in the code since 2.0. That's a big behavior to just kill off.
I have not had any luck doumenting the behavior.
[15:14]
vrurgWas 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,
To my view, reliance on an undocumented feature cannot be considered a good reason for not killing off bad functionality.
[15:18]
gac410Deja vu, but I'm sure there is a support or dev request somewhere that eliminates Web specifications for really really short URLs [15:19]
vrurgGoogle finds nothing. Though I don't have much time to dig too deep. [15:22]
gac410yeah, I'm not finding anything either. It would be a bit of research to try to find out when it was introduced. [15:22]
vrurgAnyway, as it seems that voting is 2:1 against my view, I can't oppose too much. ;) [15:22]
gac410I'll have to see what a change like this does to the rewritten Request parser in 2.2. It's already pretty complicated. [15:23]
vrurgWe could postpone the decision and do a little more research. [15:23]
gac410y,
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.
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.
Nope.... This came in later Foswiki 2.0.0 does NOT default to topic. So I apologize to sven et al.
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.
er. It only applies if the topic is missing. WebLeftBar was a bad example.
jeeze, It only applies if the topic exists.
Anyway, this behavior is in Foswiki 2.0.0 so it has been around for a long time.
[15:26]
vrurgBut 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. ;) [15:40]
gac410It 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.
And then uses that and the trailing / to decide if it might be a webname or if it exists, a topic.
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
So it's an unintended side effect.
gac410 is the goat.
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.
And the rewrite with 2.2 attempted to be very strict, with unit tests, and fixed the "bug"
[15:42]
vrurgThanks! [15:49]
gac410Anyway, 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
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
[15:49]
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.
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
All user registration would point to USERSWEB as today. Any INCLUDE paths / tailoring would use CONFIGWEB, and the default landing page would be HOMEWEB
cu all. Thanks!
[15:57]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)