oss-sec mailing list archives
Re: xdg-open bypassing SameSite=Strict
From: Solar Designer <solar () openwall com>
Date: Tue, 24 Jun 2025 01:45:29 +0200
Hello Mingi Jung, Thank you for your report and handling of this issue. On Mon, Jun 23, 2025 at 08:59:46PM +0900, grape mingijung wrote:
During discussions with several Linux distro security teams, the following suggestions were raised: 1. Introduce an "untrusted" mode or flag in browser CLI tools for opening external URLs 2. Extend xdg-open to support passing this "untrusted" flag or context to the browser 3. Modify desktop environments or applications to invoke xdg-open with the "untrusted" option when appropriate In summary, it was suggested that the *browser should be updated first*, followed by gradual support at the xdg-open and system levels. Accordingly, the issue has been forwarded to *browser vendors*, who are currently reviewing it and exploring potential fixes.
What about having browser CLI tools instead treat URLs as untrusted by default? So in step 1, a "trusted" mode or flag could be introduced (if needed for something else), and steps 2 and 3 would be unneeded. Would this cause too much breakage? What is expected to break? Alexander
Current thread:
- xdg-open bypassing SameSite=Strict grape mingijung (Jun 23)
- Re: xdg-open bypassing SameSite=Strict Solar Designer (Jun 23)
- Re: xdg-open bypassing SameSite=Strict grape mingijung (Jun 24)
- Re: xdg-open bypassing SameSite=Strict Simon McVittie (Jun 24)
- Re: xdg-open bypassing SameSite=Strict Anton Luka Šijanec (Jun 24)
- Re: xdg-open bypassing SameSite=Strict Gabriel Corona (Jun 24)
- Re: xdg-open bypassing SameSite=Strict Lucas Holt (Jun 24)
- Re: xdg-open bypassing SameSite=Strict Solar Designer (Jun 23)
