Merge from RV/LA port

.golangci.yml

@@ -0,0 +1,4 @@
+# For documentation, see https://golangci-lint.run/usage/configuration/
+linters:
+  enable:
+    - gofumpt

CHANGELOG

@@ -2,6 +2,31 @@ libseccomp-golang: Releases
 ===============================================================================
 https://github.com/seccomp/libseccomp-golang
 
+* Version 0.10.0 - June 9, 2022
+- Minimum supported version of libseccomp bumped to v2.3.1
+- Add seccomp userspace notification API (ActNotify, filter.*Notif*)
+- Add filter.{Get,Set}SSB (to support SCMP_FLTATR_CTL_SSB)
+- Add filter.{Get,Set}Optimize (to support SCMP_FLTATR_CTL_OPTIMIZE)
+- Add filter.{Get,Set}RawRC (to support SCMP_FLTATR_API_SYSRAWRC)
+- Add ArchPARISC, ArchPARISC64, ArchRISCV64
+- Add ActKillProcess and ActKillThread; deprecate ActKill
+- Add go module support
+- Return ErrSyscallDoesNotExist when unable to resolve a syscall
+- Fix some functions to check for both kernel level API and libseccomp version
+- Fix MakeCondition to use sanitizeCompareOp
+- Fix AddRule to handle EACCES (from libseccomp >= 2.5.0)
+- Updated the main docs and converted to README.md
+- Added CONTRIBUTING.md, SECURITY.md, and administrative docs under doc/admin
+- Add GitHub action CI, enable more linters
+- test: test against various libseccomp versions
+- test: fix and simplify execInSubprocess
+- test: fix APILevelIsSupported
+- Refactor the Errno(-1 * retCode) pattern
+- Refactor/unify libseccomp version / API level checks
+- Code cleanups (linter, formatting, spelling fixes)
+- Cleanup: use errors.New instead of fmt.Errorf where appropriate
+- Cleanup: remove duplicated cgo stuff, redundant linux build tag
+
 * Version 0.9.1 - May 21, 2019
 - Minimum supported version of libseccomp bumped to v2.2.0
 - Use Libseccomp's `seccomp_version` API to retrieve library version

SUBMITTING_PATCHES → CONTRIBUTING.md

@@ -1,56 +1,31 @@
-How to Submit Patches to the libseccomp Project
+How to Submit Patches to the libseccomp-golang Project
 ===============================================================================
 https://github.com/seccomp/libseccomp-golang
 
 This document is intended to act as a guide to help you contribute to the
-libseccomp project.  It is not perfect, and there will always be exceptions
-to the rules described here, but by following the instructions below you
-should have a much easier time getting your work merged with the upstream
+libseccomp-golang project.  It is not perfect, and there will always be
+exceptions to the rules described here, but by following the instructions below
+you should have a much easier time getting your work merged with the upstream
 project.
 
-* Test Your Code
+## Test Your Code Using Existing Tests
 
-There are two possible tests you can run to verify your code.  The first test
-is used to check the formatting and coding style of your changes, you can run
-the test with the following command:
-
-	# make check-syntax
-
-... if there are any problems with your changes a diff/patch will be shown
-which indicates the problems and how to fix them.
-
-The second possible test is used to ensure the sanity of your code changes
-and to test these changes against the included tests.  You can run the test
-with the following command:
+A number of tests and lint related recipes are provided in the Makefile, if
+you want to run the standard regression tests, you can execute the following:
 
 	# make check
 
-... if there are any faults or errors they will be displayed.
-
-* Generate the Patch(es)
-
-Depending on how you decided to work with the libseccomp code base and what
-tools you are using there are different ways to generate your patch(es).
-However, regardless of what tools you use, you should always generate your
-patches using the "unified" diff/patch format and the patches should always
-apply to the libseccomp source tree using the following command from the top
-directory of the libseccomp sources:
-
-	# patch -p1 < changes.patch
+In order to use it, the 'golangci-lint' tool is needed, which can be found at:
 
-If you are not using git, stacked git (stgit), or some other tool which can
-generate patch files for you automatically, you may find the following command
-helpful in generating patches, where "libseccomp.orig/" is the unmodified
-source code directory and "libseccomp/" is the source code directory with your
-changes:
+* https://github.com/golangci/golangci-lint
 
-	# diff -purN libseccomp-golang.orig/ libseccomp-golang/
+## Add New Tests for New Functionality
 
-When in doubt please generate your patch and try applying it to an unmodified
-copy of the libseccomp sources; if it fails for you, it will fail for the rest
-of us.
+Any submissions which add functionality, or significantly change the existing
+code, should include additional tests to verify the proper operation of the
+proposed changes.
 
-* Explain Your Work
+## Explain Your Work
 
 At the top of every patch you should include a description of the problem you
 are trying to solve, how you solved it, and why you chose the solution you
@@ -59,7 +34,7 @@ if you can describe/include a reproducer for the problem in the description as
 well as instructions on how to test for the bug and verify that it has been
 fixed.
 
-* Sign Your Work
+## Sign Your Work
 
 The sign-off is a simple line at the end of the patch description, which
 certifies that you wrote it or otherwise have the right to pass it on as an
@@ -97,16 +72,49 @@ your real name, saying:
 
 	Signed-off-by: Random J Developer <random@developer.example.org>
 
-* Email Your Patch(es)
+You can add this to your commit description in `git` with `git commit -s`
+
+## Post Your Patches Upstream
+
+The libseccomp project accepts both GitHub pull requests and patches sent via
+the mailing list.  GitHub pull requests are preferred.  This sections below
+explain how to contribute via either method. Please read each step and perform
+all steps that apply to your chosen contribution method.
+
+### Submitting via Email
+
+Depending on how you decided to work with the libseccomp code base and what
+tools you are using there are different ways to generate your patch(es).
+However, regardless of what tools you use, you should always generate your
+patches using the "unified" diff/patch format and the patches should always
+apply to the libseccomp source tree using the following command from the top
+directory of the libseccomp sources:
+
+	# patch -p1 < changes.patch
+
+If you are not using git, stacked git (stgit), or some other tool which can
+generate patch files for you automatically, you may find the following command
+helpful in generating patches, where "libseccomp.orig/" is the unmodified
+source code directory and "libseccomp/" is the source code directory with your
+changes:
+
+	# diff -purN libseccomp.orig/ libseccomp/
+
+When in doubt please generate your patch and try applying it to an unmodified
+copy of the libseccomp sources; if it fails for you, it will fail for the rest
+of us.
 
 Finally, you will need to email your patches to the mailing list so they can
-be reviewed and potentially merged into the main libseccomp-golang repository.
-When sending patches to the mailing list it is important to send your email in
-text form, no HTML mail please, and ensure that your email client does not
-mangle your patches.  It should be possible to save your raw email to disk and
-apply it directly to the libseccomp source code; if that fails then you likely
-have a problem with your email client.  When in doubt try a test first by
-sending yourself an email with your patch and attempting to apply the emailed
-patch to the libseccomp-golang repository; if it fails for you, it will fail
-for the rest of us trying to test your patch and include it in the main
-libseccomp-golang repository.
+be reviewed and potentially merged into the main libseccomp repository.  When
+sending patches to the mailing list it is important to send your email in text
+form, no HTML mail please, and ensure that your email client does not mangle
+your patches.  It should be possible to save your raw email to disk and apply
+it directly to the libseccomp source code; if that fails then you likely have
+a problem with your email client.  When in doubt try a test first by sending
+yourself an email with your patch and attempting to apply the emailed patch to
+the libseccomp repository; if it fails for you, it will fail for the rest of
+us trying to test your patch and include it in the main libseccomp repository.
+
+### Submitting via GitHub
+
+See [this guide](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request) if you've never done this before.

Makefile

@@ -4,7 +4,7 @@
 
 all: check-build
 
-check: vet test
+check: lint test
 
 check-build:
 	go build
@@ -16,11 +16,16 @@ fix-syntax:
 	gofmt -w .
 
 vet:
-	go vet -v
+	go vet -v ./...
+
+# Previous bugs have made the tests freeze until the timeout. Golang default
+# timeout for tests is 10 minutes, which is too long, considering current tests
+# can be executed in less than 1 second. Reduce the timeout, so problems can
+# be noticed earlier in the CI.
+TEST_TIMEOUT=10s
 
 test:
-	go test -v
+	go test -v -timeout $(TEST_TIMEOUT)
 
 lint:
-	@$(if $(shell which golint),true,$(error "install golint and include it in your PATH"))
-	golint -set_exit_status
+	golangci-lint run .

README.md

@@ -0,0 +1,59 @@
+![libseccomp Golang Bindings](https://github.com/seccomp/libseccomp-artwork/blob/main/logo/libseccomp-color_text.png)
+===============================================================================
+https://github.com/seccomp/libseccomp-golang
+
+[![Go Reference](https://pkg.go.dev/badge/github.com/seccomp/libseccomp-golang.svg)](https://pkg.go.dev/github.com/seccomp/libseccomp-golang)
+[![validate](https://github.com/seccomp/libseccomp-golang/actions/workflows/validate.yml/badge.svg)](https://github.com/seccomp/libseccomp-golang/actions/workflows/validate.yml)
+[![test](https://github.com/seccomp/libseccomp-golang/actions/workflows/test.yml/badge.svg)](https://github.com/seccomp/libseccomp-golang/actions/workflows/test.yml)
+
+The libseccomp library provides an easy to use, platform independent, interface
+to the Linux Kernel's syscall filtering mechanism.  The libseccomp API is
+designed to abstract away the underlying BPF based syscall filter language and
+present a more conventional function-call based filtering interface that should
+be familiar to, and easily adopted by, application developers.
+
+The libseccomp-golang library provides a Go based interface to the libseccomp
+library.
+
+## Online Resources
+
+The library source repository currently lives on GitHub at the following URLs:
+
+* https://github.com/seccomp/libseccomp-golang
+* https://github.com/seccomp/libseccomp
+
+Documentation for this package is also available at:
+
+* https://pkg.go.dev/github.com/seccomp/libseccomp-golang
+
+## Verifying Releases
+
+Starting with libseccomp-golang v0.10.0, the git tag corresponding to each
+release should be signed by one of the libseccomp-golang maintainers.  It is
+recommended that before use you verify the release tags using the following
+command:
+
+	% git tag -v <tag>
+
+At present, only the following keys, specified via the fingerprints below, are
+authorized to sign official libseccomp-golang release tags:
+
+	Paul Moore <paul@paul-moore.com>
+	7100 AADF AE6E 6E94 0D2E  0AD6 55E4 5A5A E8CA 7C8A
+
+	Tom Hromatka <tom.hromatka@oracle.com>
+	47A6 8FCE 37C7 D702 4FD6  5E11 356C E62C 2B52 4099
+
+	Kir Kolyshkin <kolyshkin@gmail.com>
+	C242 8CD7 5720 FACD CF76  B6EA 17DE 5ECB 75A1 100E
+
+More information on GnuPG and git tag verification can be found at their
+respective websites: https://git-scm.com/docs/git and https://gnupg.org.
+
+## Installing the package
+
+	% go get github.com/seccomp/libseccomp-golang
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md).

SECURITY.md

@@ -0,0 +1,48 @@
+The libseccomp-golang Security Vulnerability Handling Process
+===============================================================================
+https://github.com/seccomp/libseccomp-golang
+
+This document document attempts to describe the processes through which
+sensitive security relevant bugs can be responsibly disclosed to the
+libseccomp-golang project and how the project maintainers should handle these
+reports.  Just like the other libseccomp-golang process documents, this
+document should be treated as a guiding document and not a hard, unyielding set
+of regulations; the bug reporters and project maintainers are encouraged to
+work together to address the issues as best they can, in a manner which works
+best for all parties involved.
+
+### Reporting Problems
+
+Problems with the libseccomp-golang library that are not suitable for immediate
+public disclosure should be emailed to the current libseccomp-golang
+maintainers, the list is below.  We typically request at most a 90 day time
+period to address the issue before it is made public, but we will make every
+effort to address the issue as quickly as possible and shorten the disclosure
+window.
+
+* Paul Moore, paul@paul-moore.com
+* Tom Hromatka, tom.hromatka@oracle.com
+* Kir Kolyshkin, kolyshkin@gmail.com
+
+### Resolving Sensitive Security Issues
+
+Upon disclosure of a bug, the maintainers should work together to investigate
+the problem and decide on a solution.  In order to prevent an early disclosure
+of the problem, those working on the solution should do so privately and
+outside of the traditional libseccomp-golang development practices.  One
+possible solution to this is to leverage the GitHub "Security" functionality to
+create a private development fork that can be shared among the maintainers, and
+optionally the reporter.  A placeholder GitHub issue may be created, but
+details should remain extremely limited until such time as the problem has been
+fixed and responsibly disclosed.  If a CVE, or other tag, has been assigned to
+the problem, the GitHub issue title should include the vulnerability tag once
+the problem has been disclosed.
+
+### Public Disclosure
+
+Whenever possible, responsible reporting and patching practices should be
+followed, including notification to the linux-distros and oss-security mailing
+lists.
+
+* https://oss-security.openwall.org/wiki/mailing-lists/distros
+* https://oss-security.openwall.org/wiki/mailing-lists/oss-security