#1146723 apt-transport-https: Seccomp prevented execution of syscall 0000000193 on architecture amd64

Package:
apt
Source:
apt
Description:
commandline package manager
Submitter:
Francois Marier
Date:
2026-09-05 09:53:01 UTC
Severity:
normal
#1146723#5
Date:
2026-09-04 19:19:51 UTC
From:
To:
I ran into the following problem running `apt update` with HTTPS sources
with seccomp enabled:

    # apt update
     **** Seccomp prevented execution of syscall 0000000193 on architecture amd64 ****

     **** Seccomp prevented execution of syscall 0000000193 on architecture amd64 ****

     **** Seccomp prevented execution of syscall 0000000193 on architecture amd64 ****
    Error: Method https has died unexpectedly!
    Error: Sub-process https returned an error code (31)

I worked around it by putting the following in my /etc/apt/apt.conf.d/30seccomp:

    APT::Sandbox::Seccomp "1";
    APT::Sandbox::Seccomp::allow { "fgetxattr" };

and then another syscall got blocked:

    # apt update
     **** Seccomp prevented execution of syscall 0000000190 on architecture amd64 ****

     **** Seccomp prevented execution of syscall 0000000190 on architecture amd64 ****

     **** Seccomp prevented execution of syscall 0000000190 on architecture amd64 ****
    Error: Method https has died unexpectedly!

and so my final work-around ended up being:

    APT::Sandbox::Seccomp "1";
    APT::Sandbox::Seccomp::allow { "fgetxattr"; "fsetxattr" };

Francois
#1146723#10
Date:
2026-09-05 09:44:41 UTC
From:
To:
Am Fri, Sep 04, 2026 at 12:19:51PM -0700, schrieb Francois Marier:
[…]

Your "workaround" includes enabling seccomp first, which is not enabled
by default for a long time (~ 1.6~rc1 on 06 Apr 2018) as keeping track
of syscall naming changes across all supported architectures in Debian
(and beyond) seems not attainable for the current team nor have we
a good recovery scheme for users running into problems (sure, they can
figure out the options like you did, but I suppose if we shipped that by
default there should be an easy way to disable it, so users have a
non-arcane upgrade path than issues like this arise).

I can't find any references to those in the apt source, so maybe those
come from changing implementation in glibc wrappers of other calls.
They seem reasonable through, so adding them to the inbuilt list in
`methods/aptmethod.h` should be fine.

Would be nice to know why they are used now ~ perhaps they replace others
and/or have different names on other architectures/filesystems …


Best regards

David Kalnischkies