<div dir="auto">Got it. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Bastien Nocera <<a href="mailto:hadess@hadess.net">hadess@hadess.net</a>> schrieb am Do., 17. Sep. 2020, 16:04:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2020-09-17 at 15:38 +0200, Jörn-Ingo Weigert wrote:<br>
> Hi Bastian,nice idea. As SANE is already network capable to provide<br>
> connected scanners to the network,<br>
> (simply a network device) it make not really sense, to provide<br>
> sane(d) via Flatpak in my eyes.<br>
<br>
I have no plans on running saned inside the sandbox. It's about running<br>
a server on the outside of the sandbox, talking to the real hardware,<br>
so that applications don't need direct hardware access.<br>
<br>
> however, having SANE-based applications like XSane/ scan-image as<br>
> Flatpak version, maybe a nice idea.<br>
<br>
Most of them are blocking on having a scanner portal, which is what<br>
this is about. For example:<br>
<a href="https://github.com/flathub/flathub/pull/1111" rel="noreferrer noreferrer" target="_blank">https://github.com/flathub/flathub/pull/1111</a><br>
<br>
And paperwork needs access to all the devices, and ship its own sane-<br>
backends, which means it only works with the scanners supported by<br>
sane-backends:<br>
<a href="https://github.com/flathub/work.openpaper.Paperwork" rel="noreferrer noreferrer" target="_blank">https://github.com/flathub/work.openpaper.Paperwork</a><br>
<br>
> But for this you don't need to modify saned. ...<br>
<br>
You need to, if you don't want saned listening on the network, being<br>
auto-activatable, and being able to add a portal/proxy in between so<br>
that scanner access is a changeable permission.<br>
<br>
We can't easily filter network calls, and most scanner apps don't need<br>
network access, so giving them network access opens the sandbox for no<br>
good reason.<br>
<br>
> Or do I miss here something?<br>
<br>
<br>
<br>
</blockquote></div>