Support accessing host trusted certificates by alexlarsson · Pull Request #1757 · flatpak/flatpak

alexlarsson · 2018-06-07T08:10:45Z

If p11-kit server is installed on the host, we spawn a copy of this, forwarding the access to the p11-kit trust module in a read-only way.

We then (if the above worked) bind mount the socket as /run/user/$UID/p11-kit/pkcs11 in the sandbox, which is the default socket path for the p11-kit-client module.

We also add a configuration file in /etc/pkcs11/modules/p11-kit-trust.module that makes the trust module actually load the client module instead. This means applications automatically switch to using the host certs for trust if possible, and use the runtime ca-certificates otherwise.

Additionally we add a config file that always disables pkcs user config merging, because pkcs11 modules on the host are unlikely to work in a random runtime.

This does the same as RequestMonitor, but returns the status via a a{sv} so that its more extensible.

If p11-kit server is installed on the host, we spawn a copy of this, forwarding the access to the p11-kit trust module in a read-only way. We then (if the above worked) bind mount the socket as /run/user/$UID/p11-kit/pkcs11 in the sandbox, which is the default socket path for the p11-kit-client module. We also add a configuration file in /etc/pkcs11/modules/p11-kit-trust.module that makes the trust module actually load the client module instead. This means applications automatically switch to using the host certs for trust if possible, and use the runtime ca-certificates otherwise. Additionally we add a config file that always disables pkcs user config merging, because pkcs11 modules on the host are unlikely to work in a random runtime.

alexlarsson · 2018-06-07T08:17:26Z

@valentindavid So, i tried this with the 1.8 runtime, and it seems to fail because:

flatpak run -d --command=strace org.freedesktop.Sdk//unstable p11tool --list-all-trusted 2>&1 | grep pkcs11/modules
openat(AT_FDCWD, "/home/alex/.config/pkcs11/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/etc/pkcs11/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

i.e. p11-kit reads the config from /usr/etc, not /etc, so it will not pick up the /etc/pkcs11/modules/p11-kit-trust.module added by flatpak. Could you fix this in fd.o?

alexlarsson · 2018-06-07T12:25:18Z

@rh-atomic-bot r+

rh-atomic-bot · 2018-06-07T12:25:18Z

📌 Commit 63a1165 has been approved by alexlarsson

rh-atomic-bot · 2018-06-07T12:25:24Z

⌛ Testing commit 63a1165 with merge 66b2ff4...

If p11-kit server is installed on the host, we spawn a copy of this, forwarding the access to the p11-kit trust module in a read-only way. We then (if the above worked) bind mount the socket as /run/user/$UID/p11-kit/pkcs11 in the sandbox, which is the default socket path for the p11-kit-client module. We also add a configuration file in /etc/pkcs11/modules/p11-kit-trust.module that makes the trust module actually load the client module instead. This means applications automatically switch to using the host certs for trust if possible, and use the runtime ca-certificates otherwise. Additionally we add a config file that always disables pkcs user config merging, because pkcs11 modules on the host are unlikely to work in a random runtime. Closes: #1757 Approved by: alexlarsson

rh-atomic-bot · 2018-06-07T12:34:57Z

☀️ Test successful - status-papr
Approved by: alexlarsson
Pushing 66b2ff4 to master...

LorbusChris · 2019-02-12T15:20:38Z

@alexlarsson on Silverblue my host CA certs aren't picked up by neither the Firefox Nightly nor the Riot.im flatpaks. I had hoped this would be fixed by the recent ssl cert parsing fix, but apparently it wasn't. Any more ideas how to get this to work?

Ref: flathub/im.riot.Riot#28

matthiasclasen · 2019-02-12T16:27:17Z

please file a new issue

LorbusChris · 2019-10-08T16:25:39Z

new issue is at #2721

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 containers#626

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. Verions of lsof from 4.88 to older than 4.94.0 always select the file descriptor field [2], and these are present in versions of Ubuntu from 16.04 to 22.04. This needs to be factored in as long as a Ubuntu 22.04 host is used to run the CI. One option is to always select the file descriptor field even though it's not really needed for the tests. The ubuntu-toolbox:22.04 has been failing to rebuild [3]: STEP 6/10: RUN sed -Ei '/apt-get (update|upgrade)/s/^/#/' /usr/local/sbin/unminimize && apt-get update && yes | /usr/local/sbin/unminimize && DEBIAN_FRONTEND=noninteractive apt-get -y install ubuntu-minimal ubuntu-standard libnss-myhostname flatpak-xdg-utils $(cat extra-packages | xargs) && rm -rd /var/lib/apt/lists/* ... ... (Reading database ... 100% (Reading database ... 4387 files and directories currently installed.) Preparing to unpack .../libc-bin_2.35-0ubuntu3.9_arm64.deb ... Unpacking libc-bin (2.35-0ubuntu3.9) over (2.35-0ubuntu3.9) ... Setting up libc-bin (2.35-0ubuntu3.9) ... qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) dpkg: error processing package libc-bin (--configure): installed libc-bin package post-installation script subprocess returned error exit status 139 Errors were encountered while processing: libc-bin E: Sub-process /usr/bin/dpkg returned an error code (1) ... It's probably some network problem because it doesn't reliably occur everywhere. Until this gets sorted out, Toolbx containers created from the ubuntu-toolbox:22.04 won't have access to the CA certificates from the host. The fedora-toolbox and the UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 [2] lsof commit 811dc78cc6404cb3 lsof-org/lsof@811dc78cc6404cb3 lsof-org/lsof#125 lsof-org/lsof#103 [3] containers#1634 containers#1643 containers#626

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. The UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 containers#626

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. Jsut like Flatpak, the singleton 'p11-kit server' process is not terminated, when the last 'enter' or 'run' command exits. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. The UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. The CI needs to be run without 'p11-kit server' because the lingering singleton process causes Bats to hang when tearing down the suite of system tests [2]. To terminate the 'p11-kit server' instance run by the system tests, it needs to be distinguishable from the instance run by 'normal' use of Toolbx by the user. One way to do this is to isolate the host operating system's XDG_RUNTIME_DIR from the system tests. Unfortunately, this is easier said than done [3]. So, this workaround has to suffice until the problem is solved. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 [2] https://bats-core.readthedocs.io/en/stable/writing-tests.html [3] containers#1652 containers#626

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. Jsut like Flatpak, the singleton 'p11-kit server' process is not terminated, when the last 'enter' or 'run' command exits. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. The UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. The CI needs to be run without 'p11-kit server' because the lingering singleton process causes Bats to hang when tearing down the suite of system tests [2]. To terminate the 'p11-kit server' instance run by the system tests, it needs to be distinguishable from the instance run by 'normal' use of Toolbx by the user. One way to do this is to isolate the host operating system's XDG_RUNTIME_DIR from the system tests. Unfortunately, this is easier said than done [3]. So, this workaround has to suffice until the problem is solved. On the Ubuntu 22.04 CI nodes, it's not possible to remove the p11-kit package that provides 'p11-kit server', because it leads to: $ sudo dpkg --purge p11-kit dpkg: dependency problems prevent removal of p11-kit: adoptium-ca-certificates depends on p11-kit. Therefore, as a workaround only the /usr/libexec/p11-kit/p11-kit-server binary that provides the 'server' command is removed. The rest of the p11-kit package is left untouched. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 [2] https://bats-core.readthedocs.io/en/stable/writing-tests.html [3] containers#1652 containers#626

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. Just like Flatpak, the singleton 'p11-kit server' process is not terminated, when the last 'enter' or 'run' command exits. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. The UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. The CI needs to be run without 'p11-kit server' because the lingering singleton process causes Bats to hang when tearing down the suite of system tests [2]. To terminate the 'p11-kit server' instance run by the system tests, it needs to be distinguishable from the instance run by 'normal' use of Toolbx by the user. One way to do this is to isolate the host operating system's XDG_RUNTIME_DIR from the system tests. Unfortunately, this is easier said than done [3]. So, this workaround has to suffice until the problem is solved. On the Ubuntu 22.04 CI nodes, it's not possible to remove the p11-kit package that provides 'p11-kit server', because it leads to: $ sudo dpkg --purge p11-kit dpkg: dependency problems prevent removal of p11-kit: adoptium-ca-certificates depends on p11-kit. Therefore, as a workaround only the /usr/libexec/p11-kit/p11-kit-server binary that provides the 'server' command is removed. The rest of the p11-kit package is left untouched. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 [2] https://bats-core.readthedocs.io/en/stable/writing-tests.html [3] containers#1652 containers#626

This uses the same approach taken by Flatpak [1] to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system. Any program that uses PKCS containers#11 to access CA certificates should see the same ones both inside the container and on the host. During every 'enter' and 'run' command, toolbox(1) ensures that an instance of 'p11-kit server' is running on the host listening on a local file system socket that's accessible to both the container and the host. If an instance is already running, then a second one is not created. The location of the socket is injected into the container through the P11_KIT_SERVER_ADDRESS environment variable. Just like Flatpak, the singleton 'p11-kit server' process is not terminated when the last 'enter' or 'run' command exits. The Toolbx container's entry point configures it to use the p11-kit-client.so PKCS containers#11 module instead of the usual p11-kit-trust.so module. This talks to the 'p11-kit server' instance running on the host over the socket instead of reading the CA certificates that are present inside the container. However, unlike Flatpak, this doesn't use D-Bus to set up the communication between the container and the host, because when invoked as 'sudo toolbox ...' there's no user or session D-Bus instance available for the root user. This set-up is skipped if 'p11-kit server' can't be run on the host, or if the /etc/pkcs11/modules directory for configuring PKCS containers#11 modules or p11-kit-client.so are missing inside the container. None of these are considered hard dependencies to accommodate size-constrained OSes like Fedora CoreOS that might not have 'p11-kit server', and existing Toolbx containers and old images that might not have p11-kit-client.so. The UBI-based toolbox images haven't yet been updated to contain p11-kit-client.so. Until that happens, containers created from them won't have access to the CA certificates from the host. The CI needs to be run without 'p11-kit server' because the lingering singleton process causes Bats to hang when tearing down the suite of system tests [2]. To terminate the 'p11-kit server' instance run by the system tests, it needs to be distinguishable from the instance run by 'normal' use of Toolbx by the user. One way to do this is to isolate the host operating system's XDG_RUNTIME_DIR from the system tests. Unfortunately, this is easier said than done [3]. So, this workaround has to suffice until the problem is solved. On the Ubuntu 22.04 CI nodes, it's not possible to remove the p11-kit package that provides 'p11-kit server', because it leads to: $ sudo dpkg --purge p11-kit dpkg: dependency problems prevent removal of p11-kit: adoptium-ca-certificates depends on p11-kit. Therefore, as a workaround only the /usr/libexec/p11-kit/p11-kit-server binary that provides the 'server' command is removed. The rest of the p11-kit package is left untouched. [1] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 [2] https://bats-core.readthedocs.io/en/stable/writing-tests.html [3] containers#1652 containers#626

This will be used by toolbox(1) to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system [1]. Any program that uses PKCS #11 to access CA certificates should see the same ones both inside the container and on the host. This is the same approach taken by Flatpak [2]. [1] containers/toolbox#626 [2] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 https://pagure.io/fedora-kiwi-descriptions/pull-request/189

This will be used by toolbox(1) to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system [1]. Any program that uses PKCS #11 to access CA certificates should see the same ones both inside the container and on the host. This is the same approach taken by Flatpak [2]. [1] containers/toolbox#626 [2] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 https://pagure.io/fedora-kiwi-descriptions/pull-request/192

This will be used by toolbox(1) to ensure that the certificates from certificate authorities (or CAs) that are available inside a Toolbx container are kept synchronized with the host operating system [1]. Any program that uses PKCS #11 to access CA certificates should see the same ones both inside the container and on the host. This is the same approach taken by Flatpak [2]. [1] containers/toolbox#626 [2] Flatpak commit 66b2ff40f7caf3a7 flatpak/flatpak@66b2ff40f7caf3a7 flatpak/flatpak#1757 p11-glue/p11-kit#68 https://pagure.io/fedora-kiwi-descriptions/pull-request/190

alexlarsson added 2 commits June 4, 2018 16:45

session-helper: Add new more generic helper start method

3e02b08

This does the same as RequestMonitor, but returns the status via a a{sv} so that its more extensible.

alexlarsson mentioned this pull request Jun 7, 2018

Flatpak support for read-only per user p11-kit remote socket p11-glue/p11-kit#68

Closed

fixup! run: Support accessing host trusted certificates

63a1165

rh-atomic-bot closed this in b4bb890 Jun 7, 2018

alexlarsson mentioned this pull request Jun 11, 2018

Flatpak and flatpak-builder should make it easy to use trusted certificates globally #677

Closed

TingPing mentioned this pull request Nov 9, 2018

Skype can't connect via corporate MitM proxy #2297

Open

cgwalters mentioned this pull request Feb 12, 2019

Copy flatpak's approach to trusting host CA certs containers/podman#2317

Open

alexlarsson deleted the p11kit-proxy branch May 6, 2019 07:55

This was referenced Jan 29, 2020

p11-kit server >= 0.23.19 doesn't interoperate with p11-kit-client.so < 0.23.19, breaking Flatpak apps p11-glue/p11-kit#275

Closed

Applications inside flatpak don't work internet #3388

Closed

debarshiray mentioned this pull request Nov 17, 2020

Give access to the CA certificates from the host containers/toolbox#626

Open

sipsma mentioned this pull request Apr 9, 2024

core: support automatic installation of custom CA certs. dagger/dagger#7067

Merged

8 tasks

debarshiray mentioned this pull request Jun 1, 2025

Give access to the CA certificates from the host containers/toolbox#1644

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support accessing host trusted certificates#1757

Support accessing host trusted certificates#1757
alexlarsson wants to merge 3 commits intoflatpak:masterfrom
alexlarsson:p11kit-proxy

alexlarsson commented Jun 7, 2018

Uh oh!

alexlarsson commented Jun 7, 2018

Uh oh!

alexlarsson commented Jun 7, 2018

Uh oh!

rh-atomic-bot commented Jun 7, 2018

Uh oh!

rh-atomic-bot commented Jun 7, 2018

Uh oh!

rh-atomic-bot commented Jun 7, 2018

Uh oh!

LorbusChris commented Feb 12, 2019

Uh oh!

matthiasclasen commented Feb 12, 2019

Uh oh!

LorbusChris commented Oct 8, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

alexlarsson commented Jun 7, 2018

Uh oh!

alexlarsson commented Jun 7, 2018

Uh oh!

alexlarsson commented Jun 7, 2018

Uh oh!

rh-atomic-bot commented Jun 7, 2018

Uh oh!

rh-atomic-bot commented Jun 7, 2018

Uh oh!

rh-atomic-bot commented Jun 7, 2018

Uh oh!

LorbusChris commented Feb 12, 2019

Uh oh!

matthiasclasen commented Feb 12, 2019

Uh oh!

LorbusChris commented Oct 8, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants