Upgrade to the latest version of GeSHi (1.0.8)
Closed, ResolvedPublic

Description

Author: 0p9usag02

Description:
The latest version of GeSHi (1.0.7.20) has syntax highlighting for more languages, notably Haskell. This would be useful for the various Haskell wikibooks (en,ru,etc) as well as other programming language books.


Version: unspecified
Severity: minor

bzimport set Reference to bz10967.
bzimport created this task.Via LegacyAug 17 2007, 7:56 AM
bzimport added a comment.Via ConduitAug 17 2007, 1:19 PM

shinjiman wrote:

Moving this extension into SVN trunk instead of just update the version from the release is considerable, this would be simplify the update process.

http://geshi.svn.sourceforge.net/svnroot/geshi/trunk/geshi-1.0.X/src/

Nikerabbit added a comment.Via ConduitJul 11 2008, 4:37 PM

GeShi 1.0.8 also contains support for xhtml-valid pre-mode. GeSHi developer suggested using r1402 from their release branch.

Nikerabbit added a comment.Via ConduitJul 19 2008, 1:02 PM
  • Bug 14856 has been marked as a duplicate of this bug. ***
DanielFriesen added a comment.Via ConduitAug 15 2008, 8:33 PM

*** Bug 15175 has been marked as a duplicate of this bug. ***

Raymond added a comment.Via ConduitJan 21 2009, 7:29 AM
  • Bug 17098 has been marked as a duplicate of this bug. ***
demon added a comment.Via ConduitJan 22 2009, 8:27 PM

(In reply to comment #1)

Moving this extension into SVN trunk instead of just update the version from
the release is considerable, this would be simplify the update process.

http://geshi.svn.sourceforge.net/svnroot/geshi/trunk/geshi-1.0.X/src/

What about using svn externals? Then people don't have to necessarily checkout/download a separate project when they want the extension.

demon added a comment.Via ConduitJan 31 2009, 11:48 PM

Added as an external in r46666. Using r1402 as suggested above. Will be sync'd on next scap (pending review).

bzimport added a comment.Via ConduitFeb 14 2009, 9:48 AM

0p9usag02 wrote:

When is this next scap going to be? I last checked http://en.wikibooks.org/wiki/User:Kowey (which has a sample of Haskell code) on 2009-02-14, but it's still not rendering. Thanks!

Raymond added a comment.Via ConduitFeb 18 2009, 9:04 AM

A scap was done last night but WMF servers are still using an old GeSHi version: http://test.wikipedia.org/wiki/Haskell

GeSHi could not find the language haskell (using path /home/wikipedia/common/php-1.5/lib/GeSHi-1.0.7.19-wm1/geshi/) (code 2)

bzimport added a comment.Via ConduitMar 1 2009, 2:29 PM

herd wrote:

Just a note, if my prediction is correct, on the next upgrade of GeSHi the borders will disappear from all Geshi-generated <pre> with no easy way to re-add it (see bug 16324 for possible solution vector). So possibly get ready for several bugs "syntax hilight has no border".

Nikerabbit added a comment.Via ConduitApr 24 2009, 9:35 AM
  • Bug 18553 has been marked as a duplicate of this bug. ***
brion added a comment.Via ConduitMay 15 2009, 6:33 PM

Note current release is 1.0.8.3.

Note also that SyntaxHighlight_GeSHi currently is pulling in a geshi subdirectory via foreign SVN... need to check which one's being used, and if it needs to be more solidly defined.

demon added a comment.Via ConduitMay 15 2009, 6:41 PM

I was under the impression that WMF used a different directory than the geshi subdirectory/svn external? If so, is there any compelling reason not to, if we're providing safe external versions?

Per comment #2, the last good rev we were told to use was r1402. This is explicitly set within the external, so we're not running bleeding-edge.

brion added a comment.Via ConduitMay 15 2009, 7:01 PM

The svn external in the extension is newer than our original deployment, so we just never used it. The include paths present load it before the other one, apparently...

Looks like we've currently got a patched 1.0.7.19 in there... only difference seems to be some regex fixes (I presume for anti-DoS purposes, that's the sort of thing Tim would fix ;) and those changes are present in the release that's checked out.

Do we have a strong reason for grabbing r1402 specifically instead of picking a release tag?

bzimport added a comment.Via ConduitMay 28 2009, 1:35 PM

shinjiman wrote:

The latest GeSHi version is 1.0.8.4 (r2091 on branch), or we can grabbing the latest 1.0.x release instead of r1402?

Nikerabbit added a comment.Via ConduitMay 28 2009, 1:38 PM

BenBE> No. The only reason why 1402 seems to be mentioned seems to be a patch therein; which is applied to all subsequent revision.
BenBE> But as mentioned: they should test for 1.0.8.4 (and its RCs) to work and use this version.
BenBE> 1.0.8.2 is the latest other version without major breakages ...
BenBE> When they test, they should let me know of any defects they find so I can have a look at them.
BenBE> Then they should upgrade to 1.0.8.4 and stick with it ...

That was before 1.0.8.4 was released....

brion added a comment.Via ConduitMay 28 2009, 7:15 PM

Tim, I'm sticking this on your plate since you're doing the code review & deployment management -- probably we just need to take out our additional GeSHi copy in deployment, and make sure the copy that's pulled in via SVN is updated to a more current release.

bzimport added a comment.Via ConduitJun 8 2009, 11:20 PM

herd wrote:

Documenting this here: as of 1.15 <source lang="php">"\<"</source> produces \&lt;&lt;/span&gt; in render with the old GeSHI.

tstarling added a comment.Via ConduitJun 23 2009, 3:43 AM

(In reply to comment #14)

Looks like we've currently got a patched 1.0.7.19 in there... only difference
seems to be some regex fixes (I presume for anti-DoS purposes, that's the sort
of thing Tim would fix ;) and those changes are present in the release that's
checked out.

The version of GeSHi we're using was reviewed for security by me. I fixed several regexes that were vulnerable to algorithmic DoS attack and submitted the patches upstream.

brion added a comment.Via ConduitJun 23 2009, 11:04 PM

So are we clear to update to a more recent release, as it includes those fixes?

tstarling added a comment.Via ConduitJun 24 2009, 5:20 AM

Well, it's very likely that they will repeat the same mistakes and reintroduce O(N^2) regexes in new code, since despite my efforts they didn't understand what I was talking about and accepted my patches on trust. But reviewing for that kind of thing is time-consuming, and there are easier DoS attacks available. Their XSS security model is based on input-side escaping, it's ugly but seems to be robust against clueless contributed code. I didn't find any near misses.

I'll just put a profiling section around the parser hook to track any DoS attempts, and do the update.

I'm not at all keen about having SVN externals checked out on Wikimedia, I think we should remove them at least from that working copy, if not from the repo. Any of their developers could commit to the external moments before we do an svn up, whether it's trunk or a stable branch, and it would not show up on MW CodeReview.

tstarling added a comment.Via ConduitJun 24 2009, 6:41 AM

Updated to 1.0.8.4.

brion added a comment.Via ConduitJun 24 2009, 5:26 PM

As long as the external hits a specific revision (as I believe this one did) it should be reasonably safe, barring failure or malicious attacks on the other repository.

But I do worry it's less robust (what if the other projects' SVN server moves, drops offline, etc?) and it has performance issues -- my svn up's take a lot longer with the externals since it's contacting multiple servers.

demon added a comment.Via ConduitJun 24 2009, 5:41 PM

(In reply to comment #23)

As long as the external hits a specific revision (as I believe this one did) it
should be reasonably safe, barring failure or malicious attacks on the other
repository.

It does. We're currently pulling r1402 from their repo. Concerns about stability should be pretty ok, as long as we use an external that has been checked out for safety, and only update to later ones once they've been checked as well.

But I do worry it's less robust (what if the other projects' SVN server moves,
drops offline, etc?) and it has performance issues -- my svn up's take a lot
longer with the externals since it's contacting multiple servers.

Yeah :\ There's two externals on trunk/extensions right now, and they do slow down checkout/update a bit. I like the ease of use that having the externals provides, but it is a bottleneck. Isn't there a way to do a svn update without externals (I know you can checkout without them)?

FunPika added a comment.Via ConduitJun 24 2009, 5:56 PM

(In reply to comment #24)

Yeah :\ There's two externals on trunk/extensions right now, and they do slow
down checkout/update a bit. I like the ease of use that having the externals
provides, but it is a bottleneck. Isn't there a way to do a svn update without
externals (I know you can checkout without them)?

Yes, use --ignore-externals in your svn up commands.

bzimport added a comment.Via ConduitJun 25 2009, 10:37 PM

obsolete.fax wrote:

The update created this bug I think: https://bugzilla.wikimedia.org/show_bug.cgi?id=11274

Catrope added a comment.Via ConduitJun 25 2009, 10:40 PM

(In reply to comment #26)

The update created this bug I think:
https://bugzilla.wikimedia.org/show_bug.cgi?id=11274

Reclosing this bug, no need for it to be open. The upgrade happened, and its consequences are separate bugs.

demon added a comment.Via ConduitJun 25 2009, 10:48 PM

That, and I highly doubt software updated yesterday caused a bug filed 2 years ago ;-)

bzimport added a comment.Via ConduitJun 25 2009, 11:29 PM

obsolete.fax wrote:

Well I got the bug ids from here:

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#GeSHi_update

bzimport added a comment.Via ConduitJun 26 2009, 4:32 AM

herd wrote:

(In reply to comment #29)

Well I got the bug ids from here:

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#GeSHi_update

Then you didn't read it. The upgrade exposed a previous intrinsic flaw in the logic that was SUPPOSED to remove borders from the <pre> (but didn't), it did not "create" a bug.

This means, that for several years, the old version of GeSHi that Wikimedia has been using has ACCIDENTALLY been leaving the borders on the <pre>, and everyone has gotten used to it. When they were to be removed on upgrade, then people were likely to have complained, and so bug 16324 was opened in anticipation. A workaround for restoring the technically broken but widely seen <pre>-with-borders can be recreated with bug 16324 fixed (a class to give the border to). Bug 11274 is an alternate motivation to make an altenrate change that would have also been a solution vector (but really, bug 16324 was fixed and bug 11274 is either an upstream problem (the extension can not alter the pre classes, only the topmost div), or WORKSFORME.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.