Navigation
Home News Examples Demo Downloads FAQ Documentation Mailing Lists License
Support GeSHi!
If you're using GeSHi, why not help GeSHi out? You can link to GeSHi with this image:
Powered by GeSHi
Get the HTML

Project Status
The latest stable version of GeSHi is 1.0.8.11, released on the 19th of Aug, 2012.

Supported Languages:
*ABAP
*Actionscript
*ADA
*Apache Log
*AppleScript
*APT sources.list
*ASM (m68k)
*ASM (pic16)
*ASM (x86)
*ASM (z80)
*ASP
*AutoIT
*Backus-Naur form
*Bash
*Basic4GL
*BlitzBasic
*Brainfuck
*C
*C for Macs
*C#
*C++
*C++ (with QT)
*CAD DCL
*CadLisp
*CFDG
*CIL / MSIL
*COBOL
*ColdFusion
*CSS
*D
*Delphi
*Diff File Format
*DIV
*DOS
*DOT language
*Eiffel
*Fortran
*FourJ's Genero
*FreeBasic
*GetText
*glSlang
*GML
*gnuplot
*Groovy
*Haskell
*HQ9+
*HTML
*INI (Config Files)
*Inno
*INTERCAL
*IO
*Java
*Java 5
*Javascript
*KiXtart
*KLone C & C++
*LaTeX
*Lisp
*LOLcode
*LotusScript
*LScript
*Lua
*Make
*mIRC
*MXML
*MySQL
*NSIS
*Objective C
*OCaml
*OpenOffice BASIC
*Oracle 8 & 11 SQL
*Pascal
*Perl
*PHP
*Pixel Bender
*PL/SQL
*POV-Ray
*PowerShell
*Progress (OpenEdge ABL)
*Prolog
*ProvideX
*Python
*Q(uick)BASIC
*robots.txt
*Ruby
*Ruby on Rails
*SAS
*Scala
*Scheme
*Scilab
*SDLBasic
*Smalltalk
*Smarty
*SQL
*T-SQL
*TCL
*thinBasic
*TypoScript
*Uno IDL
*VB.NET
*Verilog
*VHDL
*VIM Script
*Visual BASIC
*Visual Fox Pro
*Visual Prolog
*Whitespace
*Winbatch
*Windows Registry Files
*X++
*XML
*Xorg.conf

GeSHi 1.0.8.11 is the current stable release, with eighteen new languages and bug fixes over the last release.

GeSHi 1.1.2alpha5 is the current latest version from the development branch, with full C support (see the GeSHi development website).
Subscribe
RSS 2
Mailing Lists
HomeNewsExamplesDemoDownloadsFAQDocumentationMailing ListsLicense 
11:27 am GMT

GeSHi News

Here's where you can find out all the latest news about GeSHi - new releases, bug fixes and general errata.

Security companies, distributors and reading ...
05/11/2008
There are moments, when a developer leans back after a release, concentrating on planning work for the next release to come and suddenly gets a mail on the devel list telling him about an security advisory about a bug he himself fixed about two months ago. For economy reasons the publically accessible news entry for users and developers contains the information on two distinct problems: One arbitrary remote code execution issue, which requires a system to be compromised by itself already (controlled by the attacker) or affected by another remote code execution issue in other third party software that gets executed before GeSHi runs - or to make it short: The door was open BEFORE the you could use the bug. In an attackers view, that issue was unnecessary to mention, because an attacker won't use it.

So well, maybe they mixed things up and ment the Denial of Service attack you could drive against GeSHi which had an real impact - in my tests I accidentially drove one server into the corner making the owner to having to reboot it. No - they didn't notice that one because the report clearly said "fixed in 1.0.8.1" AND the impact clearly stated "remote code execution". In an attackers point of view I'd clearly prefer the bug fixed with 1.0.8 instead of relying on an issue I won't be able to take advantage of.

So please, Secunia: Read bug reports provided by vendors, before you post your notices on unnecessary information on isues not relevant for attacks. Also I'd appreciate it if you at least could write the programs names correctly that you are reporting about. Furthermore you should use the contact information provided by the project management and contact them if you don't understand things or have information for them. It's simply annoying to get informed by third-parties of an issue of near-zero revelance, when there is public information on critical issues you can use to DoS a remote system.

Well, so far for security companies, now on to Debian package maintaining: I really like Debian, except for one point: You can't use testing for reasonably current software - instead you have to use unstable or even experimental. I know, testing should become more and more stable over time until it becomes the next stable at one point, but in my oppinion that shouldn't automatically mean that you freeze a package at a point where there is enough evidence of that particular version having more than just a few minor issues compared to updated versions. Instead you're botching around in an outdated version trying to backport patches for issues that can't be easily ported there, because the code evolved. This might work for the remote code execution issue that just changed one routine, but it won't work for the Denial of Service error in 1.0.7.22 because fixing it means to actually improve the parser, which in returns means, you just could update to the latest upstream version. So if you please could drop that package botching crap and let the upstream authors decide on how to handle things or at least give them more control on their software? Thanks in advance!

On a final word after all that complaining I would like to thank the people from the MediaWiki packaging team for their great work and efforts in packaging the latest versions of GeSHi that fast after a new release has been out. Keep up your good work!

BenBE.