While reviewing our required/optional settings, I noticed that linux.seccomp.sycalls is required, but that we don'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.
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 #657, syscalls was omitempty (and therefore more optional-feeling, although there was no real Markdown spec for seccomp before #706, so it's hard to know). My current impression is that the property should be optional (and get its old omitempty back), but I'm fine either way as long as we have a consistent position.
While reviewing our required/optional settings, I noticed that
linux.seccomp.sycallsis required, but that we don'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
seccompproperty that does not needsyscallsentries, thensyscallsshould be optional.If it does not makes sense to have an empty/unset
syscallsthen it should be required and have a minimum length of one.Before #657,
syscallswasomitempty(and therefore more optional-feeling, although there was no real Markdown spec for seccomp before #706, so it's hard to know). My current impression is that the property should be optional (and get its oldomitemptyback), but I'm fine either way as long as we have a consistent position.