Before this commit, linux.seccomp.sycalls was required, but we didn't
require an entry in the array. That means '"syscalls": []' would be
technically valid, and I'm pretty sure that's not what we want.
If it makes sense to have a seccomp property that does not need
syscalls entries, then syscalls should be optional (which is what this
commit is doing).
If it does not makes sense to have an empty/unset syscalls then it
should be required and have a minimum length of one.
Before 652323c (improve seccomp format to be more expressive,
2017-01-13, #657), syscalls was omitempty (and therefore more
optional-feeling, although there was no real Markdown spec for seccomp
before 3ca5c6c, config-linux.md: fix seccomp, 2017-03-02, #706, so
it's hard to know). This commit has gone with OPTIONAL, because a
seccomp config which only sets defaultAction seems potentially valid.
The SCMP_ACT_KILL example is prompted by:
On Tue, Apr 25, 2017 at 01:32:26PM -0700, David Lyle wrote [1]:
> Technically, OPTIONAL is the right value, but unless you specify the
> default action for seccomp to be SCMP_ACT_ALLOW the result will be
> an error at run time.
>
> I would suggest an additional clarification to this fact in
> config-linux.md would be very helpful if marking syscall as
> OPTIONAL.
I've phrased the example more conservatively, because I'm not sure
that SCMP_ACT_ALLOW is the only possible value to avoid an error. For
example, perhaps a SCMP_ACT_TRACE default with an empty syscalls array
would not die on the first syscall. The point of the example is to
remind config authors that without a useful syscalls array, the
default value is very important ;).
Also add the previously-missing 'required' property to the seccomp
JSON Schema entry.
[1]: https://github.com/opencontainers/runtime-spec/pull/768#issuecomment-297156102
Signed-off-by: W. Trevor King <wking@tremily.us>
The only non-phony target (where the target name matches the output
file) is 'validate', but we need .PHONY there because the Go
dependencies are not represented in the Makefile. This commit adds
the missing .PHONY declarations to the other targets, which truly are
phony.
Signed-off-by: W. Trevor King <wking@tremily.us>
This was broken by f9dc90b0 (make link usage consistent across the
specification, 2017-02-09, #687), which updated the link label, but
not this link. Now that the link label matches the link text, we can
use the implicit link name shortcut [1].
[1]: https://daringfireball.net/projects/markdown/syntax#link
Signed-off-by: W. Trevor King <wking@tremily.us>
I expect the (undocumented) intention here is to iterate through
'names' and call seccomp_rule_add(3) or similar for each name. In
that case, an empty 'names' makes the whole syscall entry a no-op, and
with this commit we can warn users who are validating such configs.
If, on the other hand, we were comfortable with no-op syscall entries,
we'd want to make 'names' OPTIONAL.
Warning folks who accidentally empty (or don't set) 'names' seems more
useful to me, and doesn't restrict the useful config space, so that's
what I've gone with in this commit.
minItems is documented in [1], and there is an example of its use in
[2]:
"options": {
"type": "array",
"minItems": 1,
"items": { "type": "string" },
"uniqueItems": true
},
[1]: https://tools.ietf.org/html/draft-wright-json-schema-validation-00#section-5.11
[2]: http://json-schema.org/example2.html
Signed-off-by: W. Trevor King <wking@tremily.us>
It used to have this, but the omitempty was dropped in 652323cd
(improve seccomp format to be more expressive, 2017-01-13, #657).
However, the docs that landed in 3ca5c6c5 (config-linux.md: fix
seccomp, 2017-03-02, #706) list the property as optional, and if it is
optional, we can leave it unset instead of serializing an empty array.
Signed-off-by: W. Trevor King <wking@tremily.us>
This is pretty clear from the examples like:
"consoleSize": {
"height": 25,
"width": 80
}
But examples are not normative, so this commit makes the character
units normative.
Signed-off-by: W. Trevor King <wking@tremily.us>
And bump DTSTAMP for the touched VEVENTS.
com.android.calendar version 7.1.1 only displays the DESCRIPTION body,
and does not provide a link to ALTREP (in fact, I don't see any
instances of ALTREP in the source [1]). Including the README link in
the DESCRIPTION body gives folks using that calendar application an
easy way to get to the README section.
The ICS was validated with [2].
[1]: https://android.googlesource.com/platform/packages/apps/Calendar/+/android-7.1.1_r38
[2]: https://icalendar.org/validator.html
Signed-off-by: W. Trevor King <wking@tremily.us>
And bump DTSTAMP for the touched VEVENTS.
This is less DRY, but makes life easier for folks pulling up the
calendar a minute before the meeting, since they don't have to click
through to the README section. Also requested by Vincent [1] ;).
The LOCATION entry [2] seems like a reasonable location for the
conference-call page, so I've used that. Note that the URI there is a
text value; LOCATION supports URIs in ALTREP [2], but the
UberConference page isn't an "alternate text representation for the
property value" [3]. The URI in DESCRIPTION is a fallback for clients
that don't support/display LOCATION (I'm not sure if any exist, but
it's easy to play it safe). I couldn't find a more structured
location for the phone number, unless we also wanted to put that in
LOCATION.
The ICS was validated with [4].
[1]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/%23opencontainers.2017-04-05.log.html#t2017-04-05T17:55:25
[2]: https://tools.ietf.org/html/rfc5545#section-3.8.1.7
[3]: https://tools.ietf.org/html/rfc5545#section-3.2.1
[4]: https://icalendar.org/validator.html
Signed-off-by: W. Trevor King <wking@tremily.us>
Rob had been keeping the wiki up to date with links to the MeetBot
logs, but linking directly to the MeetBot logs gives us one less thing
to maintain. The meetings which are only in the wiki are 2015-07-22,
2015-08-05, 2015-08-12, 2015-08-26, 2015-09-02, 2015-09-09,
2015-09-16, 2015-09-24, 2015-09-30. The last is in MeetBot, but it
was our first MeetBot meeting, so the MeetBot logs are not great.
Signed-off-by: W. Trevor King <wking@tremily.us>
We have a few different element types in our arrays, so it's useful to
clarify the element type for the property being specified. Before
this commit:
$ sed -n 's|.*\*\*`\([^`]*\)`\*\*[^(]*(\([^,]*\),.*|\2|p' *.md | sort | uniq -c | grep array
7 array
1 array of ints
8 array of objects
13 array of strings
All of the bare 'array' instances turned out to be arrays of objects.
Signed-off-by: W. Trevor King <wking@tremily.us>