<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - invalid json generated by ipset list -output json"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1726">1726</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>invalid json generated by ipset list -output json
</td>
</tr>
<tr>
<th>Product</th>
<td>ipset
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86_64
</td>
</tr>
<tr>
<th>OS</th>
<td>Debian GNU/Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>trivial
</td>
</tr>
<tr>
<th>Priority</th>
<td>P5
</td>
</tr>
<tr>
<th>Component</th>
<td>default
</td>
</tr>
<tr>
<th>Assignee</th>
<td>netfilter-buglog@lists.netfilter.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mark@glines.org
</td>
</tr></table>
<p>
<div>
<pre>I tried to use the -output json parameter with ipset list, and found that it
does not emit valid json.
This is true in both the Debian Trixie package, version 7.19-1, as well as a
fresh ipset build from today's git.
I can see two problems with the output:
1. the "initval" field is emitted as hex, which is not a part of the json
syntax [1].
2. in combination with '-name', it seems to be printing key:value pairs in an
array, not a map.
I set up a test ipset as follows:
---
root@gir:~# ipset list
root@gir:~# ipset new test hash:ip
root@gir:~# ipset add test 1.2.3.4
root@gir:~# ipset list --output json
[
{
"name" : "test",
"type" : "hash:ip",
"revision" : 6,
"header" : {
"family" : "inet",
"hashsize" : 1024,
"maxelem" : 65536,
"bucketsize" : 12,
"initval" : 0xdcadf93b,
---
This is the point where parsing fails. The "0x" prefix is not part of the JSON
grammar [1]. Popular JSON parsers fail on this:
---
root@gir:~# ipset list -output json | jq .
jq: parse error: Invalid numeric literal at line 11, column 29
---
It is strange that the JSON spec allows hex literals for unicode characters
within strings, but not 0x-prefixes in numbers. But it is what it is.
I think that this could be resolved by emitting the value as a decimal (%d), or
as a quoted string.
When combined with the -name parameter, I see:
---
root@gir:~# ipset list -output json -name
[
"name" : "test"
]
---
The problem with this is that key:value pairs are valid in a map/object (curly
braces), but not an array (square braces). Popular JSON parsers fail on this:
---
root@gir:~# ipset list -output json -name | jq .
jq: parse error: ':' not as part of an object at line 2, column 8
---
This output looks even more odd when multiple ipsets are present.
---
root@gir:~# ipset new test2 hash:ip
root@gir:~# ipset list -output json -name
[
"name" : "test"
"name" : "test2"
]
---
If the outer braces were curly, then this would have multiple instances of the
same key at the same level. It's also missing a comma separator.
I think the best way to solve this would be to put curly braces around each
name, like this:
---
[
{ "name" : "test" },
{ "name" : "test2" }
]
---
[1]:
<a href="https://ecma-international.org/wp-content/uploads/ECMA-404_2nd_edition_december_2017.pdf">https://ecma-international.org/wp-content/uploads/ECMA-404_2nd_edition_december_2017.pdf</a>
Figure 4 and surrounding text</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>