meson.build: allow linux to build without flatpak installed

[navi-desu]

the old automake scripts would allow for building without flatpak, as the xml file would just not be copied (because it doesn't exist) so it wouldn't be used to generate files.

this allows similar behaviour by not requiring the flatpak dependency in meson.

fix for #1099

[navi-desu]

added another commit making bubblewrap not required on linux as well. as there is systems without bwrap installed that may want to build xdp,

[GeorgesStavracas]

In principle I'm fine with the first commit, but I'd like to keep bwrap as a hard dependency on Linux as it's used to validate bitmaps in a sandbox, and that's a common attack vector.

[thesamesam]

Thanks, I can understand that concern.

Unfortunately, not all architectures support seccomp, or it's still being worked on (e.g. sparc lacks it entirely and implementing seccomp can take some time for ports to a new arch too like loong).

Would an acceptable compromise be to have it on-by-default but with a warning when disabled in meson?

[GeorgesStavracas]

If there's any way for Meson to detect which platforms support seccomp, perhaps we can make the dependency check automatic? Is there any way to detect this at build time?

[TingPing]

If there's any way for Meson to detect which platforms support seccomp, perhaps we can make the dependency check automatic? Is there any way to detect this at build time?

You'd make a small test app and use cc.run() to test if seccomp runs. That would pull in a libseccomp dep just to test though.

[TingPing]

Either way neither of these should be automatically disabled.

I think it is fine to have an explicit option like platform_supports_bwrap and platform_supports_flatpak. These are expected to be enabled unless they truly don't function.

[GeorgesStavracas]

Either way neither of these should be automatically disabled.

What I have in mind is an actual Meson option, but bubblewrap is always enabled. If you try to disable it and the platform supports bubblewrap, it errors out. If the platform doesn't support bubblewrap, it errors out and suggests the disabling Meson option.

I appreciate this approach is not common, but I don't want to create any incentives for anyone to not use bubblewrap here, unless it's a critical condition like the platform not supporting it.

[navi-desu]

Either way neither of these should be automatically disabled.

neither are automatically disabled, they're just set to not required, so if present during meson build they'll be used, if not, they're skipped

What I have in mind is an actual Meson option, but bubblewrap is always enabled. If you try to disable it and the platform supports bubblewrap, it errors out. If the platform doesn't support bubblewrap, it errors out and suggests the disabling Meson option.
I appreciate this approach is not common, but I don't want to create any incentives for anyone to not use bubblewrap here, unless it's a critical condition like the platform not supporting it.

i really don't see why not let the user disable bubblewrap in their system should they really choose to not be an option. make it a meson option that needs to be passed in.

a user, compiling xdp from source, needing to pass -DNO_BWRAP_SANDBOX or similar, with a big warning on the output saying that [it's being built with no sandboxing for parsing icons and can be a security vulnerability], is enough for them to know it's not incentivized, and that they really should be sure about doing that

[TingPing]

they're just set to not required, so if present during meson build they'll be used,

They should be opt-out. Packagers are bad and always do the wrong thing.

I think a loud warning on opt-out is fine.

[thesamesam]

You're speaking to two packagers who are engaged in discussion with you to try figure out the best way of doing this. That's not helpful :(

[eli-schwartz]

What I have in mind is an actual Meson option, but bubblewrap is always enabled. If you try to disable it and the platform supports bubblewrap, it errors out. If the platform doesn't support bubblewrap, it errors out and suggests the disabling Meson option.

I appreciate this approach is not common

You are correct.

It is not common to go to all the effort of reliably detecting whether or not a platform supports a feature, getting all the information necessary to make a decision, making that decision, but then also emitting a fatal error if the builder does not manually pass a command line argument to the build system of the form:

-D i_acknowledge_the_platform_detection_code_has_detected_bwrap_availability_state_as=unavailable

Since the option as proposed performs no function whatsoever other than to emit a fatal error instructing you which value you are unconditionally required to use, you can just elide the error message, presume the correct value without actually having a project option at all, and make users feel less bad.

...

Offhand the only time I can think of where I've seen such build options is stuff like -accept-license for software that the producers of, want end users to legally acknowledge something. It's a command-line EULA.

I would never actually have to deal with this option because I'm perfectly happy to have bubblewrap installed. But if I were to ever get the proposed error message I'd feel perfectly dreadful about the software that gave it to me.

[eli-schwartz]

This results in an automagic dependency (and thus non-reproducible build artifacts) and it feels like it would probably be better to have a project option that enables flatpak support or can be explicitly disabled.

[GeorgesStavracas]

@eli-schwartz I think you misunderstood my proposal.

All I said is that I'd rather have option('sandboxed-image-validation', type: 'boolean', value: true) in meson_options.txt. Not a feature, but a boolean that defaults to true.

The common case is, this option is enabled and the host system supports and has bubblewrap. Nothing needs to be manually set in this case.

The less common case is someone passes -Dsandboxed-bitmap-validation=false. If the host system is capable of supporting bubblewrap, I propose erroring out in this case. Patrick suggests a loud warning. Either way, it must be made explicit that this is a security issue. If the host system does not support bubblewrap, the build system doesn't complain about it.

The rarest case is when sandboxed-bitmap-validation is true (either becase of the default, or because it was explicitly set) and the host system does not support bubblewrap. In this case, the build system notifies about the situation, and suggests disabling it.

If checking whether the host system supports bubblewrap or not is too complicated or annoying, the build system could unconditionally complain about disabling sandboxing.

The whole point of this is that I don't want to bear any shred of responsibility for system integrators and packagers that disable sandboxing. Anyone that chooses to disable that is on their own, and must be aware of that, even if the use case is legitimate (e.g. bubblewrap not supported). I consider anyone suggesting the build system not to be so strict to have personal responsibility to deal with issue reports and reported security breaches that can arise from this option.

[eli-schwartz]

@eli-schwartz I think you misunderstood my proposal.

I have not.

All I said is that I'd rather have option('sandboxed-image-validation', type: 'boolean', value: true) in meson_options.txt. Not a feature, but a boolean that defaults to true.

My example was clearly not literal as I clearly do not expect the option name to be "i_acknowledge_the_platform_detection_code_has_detected_bwrap_availability_state_as", but in any event I didn't describe a feature option, i described a boolean that is implemented with strings, using meson's "combo" type with two allowed values: "available" and "unavailable", defaulting to "available".

This is precisely what you suggested, except I used different English prose as the naming. My reasoning for using different English prose for the naming is that I wish to highlight an important factor: that in your proposal, the option doesn't toggle anything, it just acknowledges the choice that meson.build has already made.

The less common case is someone passes -Dsandboxed-bitmap-validation=false. If the host system is capable of supporting bubblewrap, I propose erroring out in this case. Patrick suggests a loud warning. Either way, it must be made explicit that this is a security issue. If the host system does not support bubblewrap, the build system doesn't complain about it.

This is exactly what I understood you to be suggesting, and it is exactly what I said is a bad idea and compared to "accepting a EULA". Patrick is correct here.

If checking whether the host system supports bubblewrap or not is too complicated or annoying, the build system could unconditionally complain about disabling sandboxing.

That's a fantastic idea and I 100% approve! It's the textbook standard for offering an option that the maintainers think is a bad idea but that they want users to be able to opt into if they really insist.

Unconditionally require the functionality by default -- yes, even on FreeBSD, even though you said it's dangerous and even if they legitimately cannot use bwrap they should be made aware of it, currently they are not made aware of it.

Allow anyone who wants to disable bwrap, by passing an option -Dinsecure-disable-sandboxed-image-validation=true, and if they do so, log a warning() rather than an error(), even if their system supports bwrap, even if bwrap is currently installed, and make that warning be scary and verbose and whatever else it takes to make sure that people who disable bwrap are made loudly aware that they are doing it over your protests and that it's a terrible idea.

This will be a net security improvement for platforms other than Linux, because users and system integrators will be unable to build xdp until they pass a flag disabling bwrap and in the process acknowledge that they are comfortable running it without sandboxing because they literally had to type the word "insecure" into their build recipe scripts. Currently, they might not realize it's a bad idea at all, it just sort of gets ignored, so they might be running the software and thinking it is securely sandboxed without realizing that the sandbox is not available for their platform, and using it for things they didn't really trust but were presuming that the sandbox would save them.

[TingPing]

You're speaking to two packagers who are engaged in discussion with you to try figure out the best way of doing this. That's not helpful :(

I apologize, I meant it in jest, I'm a packager myself. I just mean build options should be really hard to to the "wrong thing".

[navi-desu]

updated the changes. making flatpak-integration into a feature flag, and for bwrap, sandboxed-image-validation, a boolean that default to true, and prints a warning when set to false by the user.

[navi-desu]

changed the texts as requred

[GeorgesStavracas]

Thank you

[thesamesam]

Thank you everyone!