Add dependabot for plugin modules and update some dependencies

[djdongjin]

This PR has 5 commits:

1. A script/make target to go mod tidy all modules. This helps manual modifying deps and keep all go.mod in sync.
2. A dependabot CI. This only monitors deps in example/ and plugins/**/* directories, since they're used as plugins/binaries, whereas the root module is used as a library.
   3-5. bump up some dependencies. The updates are to use released tags or to resolve vulnerbilities.

[djdongjin]

Release notes

Sourced from github.com/opencontainers/runtime-spec's releases.

v1.1.0

Vote: opencontainers/runtime-spec#1213

Blog: https://opencontainers.org/posts/blog/2023-07-21-oci-runtime-spec-v1-1/

Breaking changes (but rather conforms to the existing runc implementation)

• config: change prestart hook spec to match reality (#1169)

Deprecations

• config-linux: mark memory.kernel[TCP] as NOT RECOMMENDED (#1093)

Additions

• cgroup: add cgroup v2 support (#1040)
• seccomp: allow to override errno return code (#1041)
• seccomp: Add support for SCMP_ACT_KILL_PROCESS (#1044)
• Update seccomp architectures to support RISCV64 (#1059)
• Add support for SCMP_ACT_KILL_THREAD (#1064)
• Add Seccomp Notify support using UNIX sockets and container metadata (#1074)
• config-linux: Add Intel RDT CMT and MBM Linux support (#1076)
• seccomp: allow to override default errno return code (#1087)
• Introduce zos as platform (#1095)
• config-linux: add idle option for container cgroup (#1136)
• config-linux: add CFS bandwidth burst (#1120)
• IDMapping field for mount point (#1143)
• schema: add cpu idle (#1145)
• add domainname spec entity (#1156)
• config-linux: add memory.checkBeforeUpdate (#1158)
• seccomp: Add flag SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV (#1161)

... (truncated)

Commits

• See full diff in compare view

[thaJeztah]

I'm a bit on the fence on enabling dependabot and updating dependencies for modules used as a library; at least not unless there were reasons that older versions of the dependencies can no longer be used; related comment in #132 (comment) as well.

Keeping dependencies on the minimum required version would adhere to go module's minimum version selection, while still allowing consumers to pick any newer, SemVer compatible, version.

[djdongjin]

Hi @thaJeztah I think dependency is a bit different than go module's minimum version.

A dependency upgrade can be:

1. Minor upgrade, doesn't impact go minimum version;
2. Minor upgrade, impact go minimum version;
3. Major upgrade, regardless if impact go minimum version or not.

at least not unless there were reasons that older versions of the dependencies can no longer be used;

I think for 1, we should do the upgrade unless there is known broken/issue. I don't think this will impact consumers, even as a library? And also this is where dependabot is used the most. For 2 and 3, we need to decide if we want to upgrade and accept/reject dependabot PRs.

Also for 1, another benefit of upgrading those deps is that we can do upgrade incrementally, which is easier for review. E.g., now this upgrade has 110+ commits since 2014: moby/sys@mountinfo/v0.6.2...mountinfo/v0.7.2.

Another benefit of dependabot is it also alerts on deps that have security issues.

Thanks! Let me know your thought :) happy to make any changes needed.

[thaJeztah]

I think for 1, we should do the upgrade unless there is known broken/issue.

Consumers can still update to a newer version, whereas the reverse is not true; if a library module updates the minimum required versions, consumers MUST upgrade as well. The result of that may be much more impactful than the impact the update has in the library module.

I'm pretty much tempted to consider it the reverse; if nothing in the code used in this (library) module use broken, what reason would there be to update? That's the whole foundation of Go module's MVSS; it specifies the minimum version needed to use a (library) module. Any version above that (which may be because a consumer does need bug-fixes from a dependency) can be selected.

[thaJeztah]

Also for 1, another benefit of upgrading those deps is that we can do upgrade incrementally, which is easier for review.
E.g., now this upgrade has 110+ commits since 2014:

I should add that that diff is quite deceiving, as moby/sys is a multi-module repository; most commits are for other modules in the same repository (and most are related to modules having been migrated to that github repository).

[djdongjin]

That's the whole foundation of Go module's MVSS; it specifies the minimum version needed to use a (library) module. Any version above that (which may be because a consumer does need bug-fixes from a dependency) can be selected.

@thaJeztah Thanks, that makes sense to me too. So IIUC, for libraries, we shouldn't upgrade dependency and golang unless something is broken or a user reports any issues? If so I can remove the commit 3 c4c205d (There are a few deps that have known security fixes, so I probably will keep those and comment on that)

Also for dependabot, since it can report security vulnerabilities from dependencies, I suggest we still add it. Here are a few next steps for this:

1. Add dependabot, reduce/disable PRs it generates, only use its security report functionality (I'm not sure if this is only enabled if you add a .github/dependabot.yml and enable dependabot).
2. Add dependabot, make it only monitor ./plugins/**/*, which are plugins (i.e., not binaries)
3. Remove it.

Let me know which one you prefer. thanks.

[djdongjin]

Hi @thaJeztah @klihub 👋 so I've updated the PR to:

• commit1: add a script and a make target that run go mod tidy for all modules to keep them in sync.
• commit2: enable dependabot for - "/examples" and - "/plugins/**/*" directories only, i.e., not the root library module /, given the other two are used as binary plugins instead of binaries.
• commt3, 4: bump up 2 unreleased deps to closest released versions.
• commit5: bump up containerd's minor version to fix vulnerbilities.

Let me know if you have any suggestions, or which commit(s) should be removed. thanks!