Demi Marie Obenour <demiobenour@gmail.com> writes:

> On 7/22/26 04:17, Alyssa Ross wrote:
>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>> 
>>> - The code doesn't validate the user-provided app ID, resulting in
>>>   worse error messages than otherwise possible.  App IDs are always
>>>   D-Bus well-known names, so there is no risk of the rules changing
>>>   in future versions of Flatpak.
>> 
>> Even though Flatpak 2 won't use D-Bus?
>
> I think I forgot that.  Is there a document with the list of Flatpak
> 2 changes anywhere?

I think the talk from Linux App Summit this year is probably the most
comprehensive thing about it so far.

>> I'm not sure I see the value?  Does normal Flatpak do these checks?
>> I don't think we need to check everything that could possibly go wrong
>> if it wouldn't be a security concern.
>
> I don't see any reason either.  There is a trick one can do to
> improve worst-case runtime, and that is to not use RESOLVE_BENEATH
> or RESOLVE_IN_ROOT.  Instead, one uses RESOLVE_NO_SYMLINKS |
> RESOLVE_NO_MAGICLINKS and checks that the path has no ".." components
> and is not absolute.  My understanding is that RESOLVE_BENEATH
> and RESOLVE_IN_ROOT require heavyweight kernel-side checks to guard
> against race conditions, and these can produce false positives.
> The other approach doesn't require these checks and so is more reliable.
> libpathrs resolves this with an ugly retry loop.
>
> It's up to you whether this change is worth making.

Sounds like premature optimization to me.  All else equal I'd rather
have code in the kernel than in Spectrum.