Last modified: 2011-04-18 13:26:07 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 28586 - YAML: strings that are the same as boolean literals
YAML: strings that are the same as boolean literals
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Roan Kattouw
Depends on:
  Show dependency treegraph
Reported: 2011-04-17 20:58 UTC by wgh
Modified: 2011-04-18 13:26 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description wgh 2011-04-17 20:58:43 UTC
For example,

Try to parse it using pyyaml, and you'll get 
{'query': {'pages': [{'ns': 0, 'pageid': 228749, 'title': False}]}}

That's because False is unquoted, and, according to specs,
it's boolean literal, when it should be a string instead.

It also doesn't escape other boolean literals found in older 1.1 specs
Comment 1 Sam Reed (reedy) 2011-04-18 09:08:14 UTC
This is really a spyc bug, and probably should be dealt with upstream (ie

It does list that it supports the 1.0 spec, no mention of 1.1 or 2. The code does also say ""It currently supports a very limited subsection of the YAML spec."

Although in core we are using a base of 0.23, I just borrowed the 0.4.5-svn from Translate, and it makes some minor changes to the output

I know we run a condensed version in core due to security constraints etc (See r42547), we have also made a few minor bugfixes to it

Might be worth getting Tim (or looking what he did) to look over the newer version, and look at forward porting it in some capacity...

Other options include using a different library (seemingly only Symfonys YAML library in PHP), else, the rest are all PHP extensions...
Comment 2 Niklas Laxström 2011-04-18 09:45:24 UTC
As far as I know the security concerns related to the behavior of the parse function have long since been fixed. My experience with different yaml implementations is that they are all broken in different, annoying ways.
Comment 3 Sam Reed (reedy) 2011-04-18 09:49:50 UTC
Please see also bug 28591
Comment 4 Sam Reed (reedy) 2011-04-18 10:03:07 UTC
Seemingly symfony does this correctly

require_once( "./sfYamlDumper.php" );

$yaml = new sfYamlDumper();

$php = 'a:1:{s:5:"query";a:1:{s:5:"pages";a:1:{i:228749;a:3:{s:6:"pageid";i:228$

var_dump( $yaml->dump( unserialize( $php ) ) );

reedy@ubuntu64-esxi:~$ php test.php
string(75) "{ query: { pages: { 228749: { pageid: 228749, ns: 0, title: 'False' } } } }"
Comment 5 Tim Starling 2011-04-18 11:04:06 UTC
The simple fix is to remove YAML support. It's a really terrible format for computer-to-computer communications, because the spec is difficult to implement and there are lots of silly little cases like this one that need special handling. I noticed this bug in spyc last time I reviewed it, but I didn't bother reporting it because there were so many other similar bugs. 

If we really have to have YAML support, I recommend writing our own formatter which uses a JSON-like subset of YAML and skips all the cute features which trip up parsers. It should stick to quoted strings and "flow collections", i.e. arrays delimited with brackets or braces. In fact if we move to YAML 1.2, we can just use FormatJson::encode(), since JSON is a subset of YAML 1.2.
Comment 6 Sam Reed (reedy) 2011-04-18 11:42:58 UTC
Comment 7 wgh 2011-04-18 13:21:48 UTC
Did you mean r86302 ?
Comment 8 Sam Reed (reedy) 2011-04-18 13:22:51 UTC
Yup. No need to reopen for that
Comment 9 wgh 2011-04-18 13:25:24 UTC
Reedy, I'm deeply sorry. Somehow selector below had "REOPENED" choice by default.
Comment 10 Sam Reed (reedy) 2011-04-18 13:26:07 UTC
Oh, weird

No harm done :)

Note You need to log in before you can comment on or make changes to this bug.