NativeMessaging portal for sandboxed browsers

This is a proposal for a new portal to enable the native messaging feature of sandboxed browser apps, which was originally discussed on the snapcraft forum.

Native messaging is a mechanism implemented in several major browsers (Chromium, Firefox, Brave, Edge, others?) that allows web extensions to communicate with a native application installed on the system.

This mechanism is used by different types of applications to provide better integration between the user’s computer and their browser / web services, for instance password management applications, searching and managing GNOME shell extensions, KDE Plasma integration, …

This currently doesn’t work in browsers (such as Firefox) packaged as flatpaks or snaps, because confinement prevents the browser from executing random executables on the user’s host (for obvious security reasons).

The native messaging host is described by a JSON metadata blob that looks something like:

{
  "name": "org.gnome.chrome_gnome_shell",
  "description": "Native connector for extensions.gnome.org",
  "path": "/usr/bin/chrome-gnome-shell",
  "type": "stdio",
  "allowed_extensions": [
    "chrome-gnome-shell@gnome.org"
  ]
}

In particular, you have:

the name that the web extension requests to talk to
the path to the program that will be executed
the list of allowed_extensions (for Firefox) or allowed_origins (for Chrome) that the server is willing to talk to

The proposal is to expose a new org.freedesktop.portal.NativeMessaging interface, with a Start(…) and a Kill(…) method (names up for debate):

<method name="Start">
  <arg type="s" name="name" direction="in"/>
  <arg type="s" name="extensionOrOrigin" direction="in"/>
  <arg type="h" name="stdin" direction="out"/>
  <arg type="h" name="stdout" direction="out"/>
</method>

When called, the service would look for a matching JSON metadata file and verify that it allows communication with the named extension. If so, it spawns an instance of the app and returns stdin and stdout file descriptors that are pipes to the equivalent descriptors of the app. The Kill(…) method would let the browser terminate the app.

This would prompt changes in browsers to use this new portal. Here in Firefox, and likely here in Chromium.

How would the issues raised here be dealt with? https://bugzilla.mozilla.org/show_bug.cgi?id=1621763#c2

This proposal seems like it's intended to solve the "Interaction" point in that comment, but not the "Discovery" point: if the browser wants to enumerate all the native messaging modules on the host, it cannot.

Do browsers need to be able to do that? (I could see this going either way, depending whether communication with a native messaging module is initiated by the extension/webapp or by the browser.)

the list of allowed_extensions (for Firefox) or allowed_origins (for Chrome) that the server is willing to talk to

Are Firefox native messaging modules and Chrome native messaging modules interchangeable? Would there ever be a situation in which a user wants to expose only a subset of native messaging modules to one of the browsers?

Are extensions and origins interchangeable?

What's the security model for allowed extensions and origins? It seems to me that in this proposal, we're implicitly trusting the browser to tell us the correct extension/origin from which it got the request (components outside the browser have no way to know whether we can believe it) - which means that filtering could equally well be done by the browser itself, as it is in non-Flatpak, non-Snap browsers, as long as the browsers have a way to read the extension's list of allowed extensions and origins themselves.

Are Firefox native messaging modules and Chrome native messaging modules interchangeable?

From the documentation you linked, it seems the answer is no: each browser has its own browser-specific search path for manifests, and it's not obvious how we would correlate those with Flatpak and Snap app-IDs (except by hard-coding).

This proposal seems like it's intended to solve the "Interaction" point in that comment, but not the "Discovery" point: if the browser wants to enumerate all the native messaging modules on the host, it cannot.

The discovery problem is a problem of the x-d-p. If an application provides a NativeMessaging app manifest on the host the portal will discover it (if it knows about all the well-known directories for each browser… urgh). If The application is in a sandbox itself and the app manifest has a path in that sandbox the portal won't be able to call it.

I don't think the browser needs to know about all existing app manifest but only react when an extension requests access to one.

How the "Interaction" problem is solved is not really clear to me. If the NativeMessaging app is in flatpak the path in the manifest is still a host path.

What's the security model for allowed extensions and origins? It seems to me that in this proposal, we're implicitly trusting the browser to tell us the correct extension/origin from which it got the request (components outside the browser have no way to know whether we can believe it) - which means that filtering could equally well be done by the browser itself, as it is in non-Flatpak, non-Snap browsers, as long as the browsers have a way to read the extension's list of allowed extensions and origins themselves.

Since the manifests are somewhere on the host and the browsers are in a sandbox they don't see the manifest. We could just as well return the allowed extensions and origins instead of checking them for the browser.

Deciding if an app should be able to access a specific or all NativeMessaging endpoints on the other hand is a really hard problem. Should we hardcore firefox and chrome? Let the user decide? What data can the user make a decision on? E.g. if a keyring application can be talked to by any application through NativeMessaging that would be really bad.

If an application provides a NativeMessaging app manifest on the host the portal will discover it (if it knows about all the well-known directories for each browser… urgh).

Being a dedicated portal for native messaging, it doesn't sound too bad that it has to know of a list of well-known directories where to search for manifests.

I haven't given much thought to endpoints packaged as flatpaks/snaps themselves, but that's an interesting prospect indeed. It sounds like the portal would need some additional logic to know where to look for them, and to invoke the right executable.

I don't think the browser needs to know about all existing app manifest but only react when an extension requests access to one.

Agreed, the browser doesn't need to discover all manifests, only to delegate to the portal when an extension requires talking to a given origin.

What's the security model for allowed extensions and origins? It seems to me that in this proposal, we're implicitly trusting the browser to tell us the correct extension/origin from which it got the request.

Yes, that's the point: the browser requests talking to a given extension/origin, and the portal handles locating the corresponding endpoint and initiating communication with it.

E.g. if a keyring application can be talked to by any application through NativeMessaging that would be really bad.

Supposedly, the portal would mediate that by informing the user which application (browser or not) is trying to launch which endpoint, and requesting permission (which might then be cached to avoid subsequent blocking dialogs). I am not familiar with the internals of x-d-p (yet), hopefully this makes sense?

Supposedly, the portal would mediate that by informing the user which application (browser or not) is trying to launch which endpoint, and requesting permission (which might then be cached to avoid subsequent blocking dialogs).

How would this look to a user?

We should try to avoid situations where we pop up a dialog that, to a non-technical user, might as well say

The application "Firefox" wants to do something.
This is probably fine, except maybe it isn't.
[ Allow ] [ Deny ]

This seems like something where it might be a lesser evil to have static permissions (in the Flatpak metadata or Snap's equivalent, similar to how access to e.g. X11 is handled), so that Firefox can contact native messaging providers that were found in Firefox directories, Chromium (and Chrome and ungoogled-Chromium) can contact native messaging providers that were found in Chromium directories, and random non-browser apps can't contact any native messaging providers.

Yes, that sounds reasonable.

That would work but it's far from ideal. Taking a step back, what we really want is for applications to communicate with each other freely through dbus. The application providing a bus should then have a policy, possibly even ask the user what to do, to decide what another app is allowed to do. That only works if apps can authenticate each other and requires something like o.fd.DBus.GetConnectionCredentials. With such a system in place there could be a new NativeMessaging scheme which has a strong security model which works with sandboxed and host apps on either side.

As a stop-gap solution the static permissions might be reasonable though.

This seems like something where it might be a lesser evil to have static permissions

We could certainly work with a static permission, similar to how the network connectivity portal decides whether to answer requests from the client. On the snapd side, we've already got a "browser-support" permission that might be an appropriate proxy for this permission (although it is also used by some Electron apps), which we could expose to x-d-p.

As far as separating out Chrome vs. Firefox native messaging hosts, I'd originally hoped we could mostly rely on the different format for extension IDs to pick the right executables. As a quick example, here are the two json files for the native messaging host for gnome-shell's browser extension:

For Firefox:

{
  "name": "org.gnome.chrome_gnome_shell",
  "description": "Native connector for extensions.gnome.org",
  "path": "/usr/bin/chrome-gnome-shell",
  "type": "stdio",
  "allowed_extensions": [
    "chrome-gnome-shell@gnome.org"
  ]
}

and for Chrome:

{
  "name": "org.gnome.chrome_gnome_shell",
  "description": "Native connector for extensions.gnome.org",
  "path": "/usr/bin/chrome-gnome-shell",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://gphhapmejobijbbhgpjhcjognlahblep/",
    "chrome-extension://olkooankbfblcebocnkjganpdmflbnbk/"
  ]
}

We could do separate portal APIs for Firefox style hosts (match on allowed_extensions) and Chrome style hosts (match on allowed_origins). But due to the different ID formats, we could essentially collapse them: searching both browsers' configuration directories and check the extension ID against both allowed_origins and allowed_extensions should reliably pick the right json file.

@oSoMoN

Based on the discussion here, there are two main deficiencies in the initial Start() API I proposed that is included at the top of this issue:

It doesn't provide a way to stop the native messaging server (@oSoMoN suggests a Kill method for this).
If we wanted to have the option of presenting an access control dialog, we'd have an active D-Bus method call waiting for the interaction to complete. We've tried to avoid that in most other cases.

For (1), the existing Session interface seems like a good fit. That would give the client a way to request the server be killed (through the Close) method, and notification if it dies for some other reason (the Closed signal). This also lets us reuse code to provide appropriate access control to the session object (i.e. ensure one confined app doesn't kill the session of another app).

For (2), while we might not show one if we go for the static permission route, it might still be worth while designing the API to allow it. So we'd probably want an API that returns a Request. We could include the stdin/stdout file descriptors in the request's Response signal broadcast, but we haven't done that anywhere else. We could alternatively provide a separate method call to get the file descriptors.

This would give an API something like:

<!-- Create a session object representing an instance of a native messaging host. -->
<method name="CreateSession">
  <arg type="a{sv}" name="options" direction="in"/>
  <arg type="o" name="handle" direction="out"/>
</method>

<!-- Start the named native messaging host. Returns a Request object that will signal success if the native messaging server could be started -->
<method name="Start">
  <arg type="o" name="session_handle" direction="in"/>
  <arg type="s" name="name" direction="in"/>
  <arg type="s" name="extensionOrOrigin" direction="in"/>
  <arg type="a{sv}" name="options" direction="in"/>
  <arg type="o" name="handle" direction="out"/>
</method>

<!-- Get the stdin/stdout file descriptors for the session. Will fail if session has not been successfully started -->
<method name="GetPipes">
  <arg type="o" name="session_handle" direction="in"/>
  <arg type="h" name="stdin" direction="out"/>
  <arg type="h" name="stdout" direction="out"/>
</method>

As with other session based APIs, sessions will automatically get killed if the D-Bus peer that created them disconnects from the bus.

@jhenstridge

Thanks for working on this @jhenstridge - I was looking at it earlier this month to see if we could get the Chrome GNOME extension working on Endless OS and someone pointed me towards this ticket.

Is the intention that the static permission is basically all or nothing? Ie with the permission, a browsers are able to access any native message host, and the browser is trusted to whatever internal sandboxing/ACLs to restrict that to the right sites, and the system vendor/admin/user outside the sandbox is in control of which native extensions they want to take that chance with?

(The reason I ask is that I was about to point out that a static permission that enabled access per native messaging host would be relatively useless, as it would require the packaging for each browser to know ahead of time which extension + host combinations the browser user might want to use. Or, a mechanism for the OS to tell Flatpak to give access all of these available hosts to all of the browsers, but that becomes essentially equivalent to "let any browser access any messaging host".)

I think a request to the user is not as bad as first thought, because the OS can take care of illustrating to the user what is being accessed, ideally making use of metadata about the messaging hosts and which package/whatever they come from. The information we gain here, which is not otherwise accessible, is confirmation from the user that the access is happening when they are trying to use it, rather than maliciously/unexpectedly in the background when the user thinks something else is going on. So you could have a dialog like:

A web browser or other application is requesting additional access to your computer:
 * Chromium
Is trying to launch:
 * Native connector for extensions.gnome.org

If you are not trying to access this functionality at this time,
please press Stop and seek assistance from $DEITY.

[ Stop ] [ Allow Always ] [ Allow Once ]

A further complication which I think is worth considering, even if we decide to implement/solve it later, is that we have >0 examples of apps themselves which would ideally be able to offer native messaging hosts. KeePassX has a Flatpak and its native messaging stuff doesn't really work unless you do some weird gymnastics at the moment. flathub/org.keepassxc.KeePassXC#29

Perhaps this becomes, at least for Flatpaks, an export mechanism similar to search providers where the export is present but requires additional user consent/action to have the export activated. This might argue in favour of the user consent mechanism because the portal could see the message host exported from the Flatpak, and check whether the user wants them to be patched together in this way.

The suggestion about static permissions was from #655 (comment). If we can come up with an understandable wording for the access control dialog, then we could certainly include that. With the API proposal above, I wanted to make sure we didn't back ourselves into the corner of never being able to show such a dialog.

As far as sandboxed native messaging servers go, I see that as a separate problem that may be best solved in the individual confinement systems. If flatpak or snapd learned how to write out a native messaging JSON metadata file in a way that a traditionally packaged browser can find, then this proposed portal would also make that server available to confined web browsers too.

The important part here would be to ensure that the command in the JSON file causes the server to be invoked with the appropriate sandboxing. I don't think KeepassXC's current approach of writing out the JSON metadata file at runtime is something we'd really want to support, since it would effectively be a sandbox escape vulnerability. But if the package maintainer could ask flatpak/snapd to create the metadata file on its behalf, then it wouldn't matter that the one KeepassXC writes out is ignored.

Sounds good - in Flatpak land exported files such as .desktop, .service, etc files are rewritten so that the Exec= line includes the appropriate flatpak run ... invocation so that the entry points from the outside world are appropriately sandboxed.

This is not the most relevant place to ask. This is an issue tracker, not a support forum.

Folks, let's keep cool. This is not an issue with xdg-desktop-portal, so that's why I asked to close. Now we have the xdg-native-messaging-proxy. I opened a bug report with Canonical so they drop the patch they carried downstream in favor of the proxy.
I'm not sure how the proxy would work with a Flatpak, but I'm trying to make work with Snap, more precisely 1Password that's the tool I use most.
I recommend to gently ask in the xdg-native-messaging-proxy if they can add some documentation about how to use the proxy. What do you think?

To give the wished status update, even though I'm an unaffiliated entity and don't speak for any party involved here:

I'm afraid there's still no solution for setups in which both the application (e.g., 1Password) and the browser (e.g., Firefox) are running in sandboxes. xdg-native-messaging-proxy currently expects applications to run on the host. See flatpak/xdg-native-messaging-proxy#9.

Implementation on the browser's side is currently stale, too. See https://bugzilla.mozilla.org/show_bug.cgi?id=1955255 for Firefox. One reason for that might be that xdg-native-messaging-proxy isn't there yet, another reason is that this solution requires distributions to ship xdg-native-messaging-proxy, which AFAIK no distribution does in stable yet (Debian ships it in testing and stable-backports, Alpine in testing, and there's an unofficial AUR package for Arch Linux, but no Fedora and no Ubuntu packages yet AFAIK).

Native Messaging has been fixed on Ubuntu with Snaps I think three years ago. They have a custom solution for native messaging since then, which is also enabled in the Firefox Snap by default. It's unlikely that they adopt xdg-native-messaging-proxy until it's actually there yet. Canonical did their homework already. This is an issue with the Flatpak ecosystem.

However, it's still possible to disfigure Flatpak's sandbox and poke holes into the sandbox to make Native Messaging work again. It kinda defies the purpose, has major limitations, but works. For KeePassXC see keepassxreboot/keepassxc#7352 (comment). Other applications (e.g., 1Password) could do similar things, but AFAIK none does (and neither does KeePassXC officially, not even unofficially, it's a third party thing…), because it's just not their job to fix this.

tl;dr: Nothing has changed from an user's perspective. From a developer's perspective, we now a different incomplete solution (xdg-native-messaging-proxy instead of the previous portal; to clarify, the portal wasn't production-ready either)

What's the most "testing ready" setup for Chrome / Firefox & 1Password / KeePassXC (all flatpak)?

Possibly, something like "Arch + AUR xdg-native-messaging-proxy build + the apps"?

Or flatpaked web browsers don't implement this feature at all yet? Or are there any WIP feature dev branches anywhere?

It would need to be tested. For now I'm just testing Firefox Snap plus 1Password without sandbox. I think KeePassXC probably is working better. 1Password still needs to work on this, and they are not very collaborative about it.

May an other Idea.
Everybody here is speaking only about password manager. Would it have more attention or bring motivation to solve the case if this Problem may look at from a case specific view.

There is a need of a way, sandboxed application could log in on certain accounts. In the best case the sandboxed application itself is not able to play man-in-the-middle, so the best solution would be that we have a way to answer such protectable data from a by user trusted source in the most secure possible way.

At least snap/flatpak provide what is needed to be as secure as possible.

Would it have more attention or bring motivation to solve the case if this Problem may look at from a case specific view.

Well, there are at least three use-cases for native messaging that I can currently think of:

Native password managers: A password manager like KeePassXC installed on the host, with the extension in the browser for accessing passwords and other login info. In this case, some "password manager"-specific portal might be useful, but I don't think it's really necessary, considering it's only a small part of the native messaging functionality (although probably the most popular). Because password managers are often provided from third-parties, having support to run them in Flatpak or Snap would be quite useful.
DE integration helpers: Some desktop environments provide browser extensions for managing DE extensions and other integration with desktop environment, like GNOME Shell Integration or Plasma Integration. In this case, since integration is often part of the DE and is designed to affect the system, sandboxed native applicications aren't as necessary, but might still be useful.
Mailvelope (and probably other similar extensions) can be used to communicate with the natively-installed GPG toolchain for signing and encrypting emails in web email clients.
PWAsForFirefox (my extension) uses native messaging with an additional native program that can install PWAs as "desktop" applications with DE integration. As this is a third-party package, having a way to distribute it as Flatpak or Snap, in a way that it could only access specific directories required for DE integration, would be useful, but this isn't currently possible.

In any case, xdg-native-messaging-proxy only solves (or more precisely, it will solve, once it is actually implemented in distros and browsers) one part of a problem: It only allows sandboxed (Flatpak/Snap) browsers to access native unsandboxed apps. However, another important feature is to allow sandboxed apps to provide themselves as a native messaging hosts for both sandboxed and unsandboxed browsers. This is currently not possible, and it doesn't appear there is any solution on the horizon.

Also, there is another thing. In other discussions about support for sandboxed native messaging hosts (#1191), there are some ideas that this could be implemented with D-Bus, so native messaging hosts register themselves as activatable D-Bus services and the browser would connect to them directly. However, I think this is not a good solution. Currently, the communication between the app and the browser is done through stdin/stdout, which works basically the same in all operating systems, and is supported in most programming languages. Handling D-Bus is more complicating and often requires additional libraries, if any even exist for the language the native messaing cost is written in. Because of this, requiring D-Bus for sandboxed native messaging hosts could make it a lot harder for app developers to implement support for native messaging on Flatpak.

However, another important feature is to allow sandboxed apps to provide themselves as a native messaging hosts for both sandboxed and unsandboxed browsers. This is currently not possible, and it doesn't appear there is any solution on the horizon.

This seems to be the main problem. Many applications that need any kind of messaging channel between them are often all distributed as Flatpaks. It is much more likely to have a KeePassXC and a Chrome both installed on one system as flatpaks rather than a combination of "flatpak & native".

So a messaging channel between flatpaks is necessary too.

This alignt with flatpak's aim to be a universal package distribution system. It goes completely against flatpak's position to NOT implement a way for 2 (or more, through a message broker topic access & subscription or likewise) flatpaks to communicate, given explicit user consent.

@swick

which AFAIK no distribution does in stable yet (Debian ships it in testing and stable-backports, Alpine in testing, and there's an unofficial AUR package for Arch Linux, but no Fedora and no Ubuntu packages yet AFAIK).

It will be in Ubuntu 26.04 and Fedora 44

https://repology.org/project/xdg-native-messaging-proxy/versions

@swick do you need this in noble-backports as well?

this solution requires distributions to ship xdg-native-messaging-proxy, which AFAIK no distribution does in stable yet

Even if similar functionality was added to xdg-desktop-portal today, no distribution would ship that version in their stable releases for a while either. Distributions can pick up x-n-m-p just as quickly as they can pick up an updated x-d-p, or just as slowly, depending on their policies.

(In fact a separate package is safer and more likely to get backported, because an updated x-d-p can cause existing functionality to regress, but merely adding x-n-m-p is unlikely to break their existing version of x-d-p. The whole point of stable releases is that they're a strategy to minimize regressions and behaviour changes.)

@smcv

@smcv Nobody claimed otherwise.

Distributions not shipping x-n-m-p isn't the issue (maybe part of it, but not the crucial one). It's great that they plan to ship it in the future, but it won't solve anything for now. Development on the browser's side is stale, too. No browser is going to use x-n-m-p right away. Mozilla is aware of x-n-m-p and wants to support it, but no idea about Google's status. But that's not the issue either. Even when x-n-m-p is shipped in all major distributions and the browser vendors finish the implementation on their side and release it, the issue will persist for the majority of users. The reason is, as I explained earlier, that even though x-n-m-p works with a sandboxed browser, it does not work with sandboxed applications (like the KeePassXC Flatpak). It will only allow the Firefox Flatpak to communicate with native applications (like a native / non-sandboxed KeePassXC). See flatpak/xdg-native-messaging-proxy#9.

Neither distributions nor browser vendors are at fault here. It's an issue in the Flatpak ecosystem which Flatpak hasn't solved in 4,5 years. x-n-m-p isn't production ready. Canonical and Firefox have solved this 3,5 years ago with Snap.

Another usecase we would need solved is browser automation from other apps, e.g. https://playwright.dev/

Status update:

It looks like support for x-n-m-p has landed in Firefox 157 (expected on 2026-09-29) 🚀

Thank you very much to the Firefox devs involved here! ❤️

Note that not all distributions ship x-n-m-p yet (see https://repology.org/project/xdg-native-messaging-proxy/versions). You can build and install it locally, though (see https://github.com/flatpak/xdg-native-messaging-proxy). ~~Don't forget to enable xdg-native-messaging-proxy.service with systemctl --user enable --now.~~

However, keep in mind that this will only allow native / non-sandboxed / host applications to talk to the Firefox Flatpak. It will not allow sandboxed applications such as the KeePassXC Flatpak to talk to the Firefox Flatpak. Unfortunately, x-n-m-p doesn't support that, and there currently don't appear to be any efforts to add support for it. Help is very much appreciated. See flatpak/xdg-native-messaging-proxy#9.

Unfortunately, I don't know anything about Chromium's progress toward supporting x-n-m-p.

@PhrozenByte

@PhrozenByte I have just managed to get xdg-native-messaging-proxy work with the KeePassXC flatpak. It appears the idea that it wouldn't work with sandboxed NM hosts is erroneous. To the contrary, it seems to work out of the box with NM hosts, whether they are sandboxed or not. Of course, I have only tried KeePassXC so far. Here is my experiment with Firefox 157 flatpak: flatpak/xdg-native-messaging-proxy#9 (comment)

@geometry1

It appears the idea that it wouldn't work with sandboxed NM hosts is erroneous.

@geometry1 I'm afraid that's not the case. It's still a workaround that violates Flatpak's sandboxing principles.

The KeePassXC Flatpak isn't supposed to write to ~/.mozilla. Under normal circumstances, it wouldn't even be able to do so. However, the KeePassXC Flatpak happens to have the --filesystem=host permission, which effectively allows it to bypass that restriction. This is still a violation of Flatpak's sandboxing principles, though.

It's also not true that there is "no need to make any modification to KeePassXC". The KeePassXC Flatpak just happens to have already made these modifications: when KeePassXC detects that it is running inside a Flatpak, it writes the NM manifest with a Flatpak-aware executable path (/var/lib/flatpak/exports/bin/org.keepassxc.KeePassXC). The KeePassXC Flatpak has furthermore added code to be able to detect when its main binary was invoked via NM. x-n-m-p aims to be a transparent proxy, though, so this will break once x-n-m-p actually gains support for sandboxed applications such as the KeePassXC Flatpak.

Regarding your instructions: You can remove step 4. The Firefox Flatpak doesn't need access to ~/.mozilla/native-messaging-hosts. Firefox will use the org.freedesktop.NativeMessagingProxy D-Bus interface to obtain the NM manifests.

It's a much nicer and simpler workaround than before, so that's definitely a good thing. But it is still a workaround.

Navigation Menu

Repository navigation

NativeMessaging portal for sandboxed browsers #655

41 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

NativeMessaging portal for sandboxed browsers #655

Description

Activity

swick commented on Nov 10, 2021

smcv commented on Nov 10, 2021

smcv commented on Nov 10, 2021

smcv commented on Nov 10, 2021

swick commented on Nov 10, 2021

oSoMoN commented on Nov 11, 2021

smcv commented on Nov 11, 2021

smcv commented on Nov 11, 2021

oSoMoN commented on Nov 11, 2021

swick commented on Nov 12, 2021

jhenstridge commented on Nov 24, 2021

jhenstridge commented on Nov 25, 2021

ramcq commented on Nov 25, 2021

jhenstridge commented on Nov 25, 2021

ramcq commented on Nov 25, 2021

41 remaining items

swick commented on Mar 12, 2026

mhalano commented on Mar 12, 2026

PhrozenByte commented on Mar 12, 2026

tsilvs commented on Mar 14, 2026

mhalano commented on Mar 14, 2026

Mannshoch commented on Mar 15, 2026

filips123 commented on Mar 15, 2026

tsilvs commented on Mar 16, 2026

bluca commented on Mar 27, 2026

smcv commented on Mar 27, 2026

PhrozenByte commented on Mar 27, 2026

razzeee commented on Apr 3, 2026

PhrozenByte commented on Sep 10, 2026

geometry1 commented on Oct 2, 2026

PhrozenByte commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions