Re: Bug#994451: golang-github-containers-common: secomp.json does not include newer syscall used by stable kernel/glibc on arm

User: release.debian.org@packages.debian.org
Usertags: pu
Tags: bullseye
Severity: normal

stop

sorry for the abrupt ending of the previous mail.

I'm attaching the debdiffs for the three uploads to this email.

I'm happy to do the 3 uploads at any time. Please let me know what you think.

On Mon, Sep 27, 2021 at 12:08 PM Reinhard Tartler <siretart@gmail.com> wrote:

On Thu, Sep 16, 2021 at 4:18 AM Bastien Roucariès <roucaries.bastien@gmail.com> wrote:
Package: golang-github-containers-common
Version: 0.33.4+ds1-1
Severity: critical
Tags: upstream
Forwarded: https://github.com/containers/common/commit/42d1db16bfc0dbaee5781d230dc2bcbaa0849c6e
Control: fixed -1 0.42.1+ds1-1

Dear Maintainer,

golang-github-containers-common in stable does not include recent syscall used
by stable kernel/glibc breaking in my case simple container that do unattended-
upgrade on arm
particularly syscall=436 that is timer_settime64

I believe this should be fixed in a point release.

I agree. I realized that these syscall changes also affect amd64. I was able to reproduce the issue
by running a distribution that ships with glibc 2.34, such as ubuntu impish. The testcase would be:

$ podman run --rm -it ubuntu:impish sh -c 'apt update -qq && apt -y full-upgrade && apt install -y libc6 jq'

The symptom is described in more detail at https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/1943049

The problem here is that the issue is not simply dealt with updating the secomp.json file, but also some code changes are required
that allow setting the default return value for some syscalls. This means that in order to fix this issue in stable, 3 uploads are needed:

- golang-github-opencontainers-specs
- golang-github-containers-common
- libpod

I'm cloning this bug appropriately so that these uploads can be tracked separately.
For now,I've backported and verified the changes. For your convenience, I've uploaded the packages I got so far to
https://people.debian.org/~siretart/bug.994451/

BTW I strongly believe that seccomp.json is a config file and should be
shipped in /etc and 988443 should also be shipped in stable.

I could get convinced if the issue was fixable by just upading the seccomp.json policy file.
Sadly, that's not the case.

Stable Release team, I think this bug should be cloned with those instructions:

--
regards,
Reinhard

regards,
Reinhard