[sane-devel] Sandboxing scanner applications

[Bastien Nocera]

On Thu, 2020-09-17 at 16:55 +0200, Jörn-Ingo Weigert wrote:
> Got it. 

Any comments about the questions in my original mail? (dependencies,
whether to create a new project, or build it in sane-backends/sane-
frontends)

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