libsane and acl group selection in udev rules

[Martin Owens]

You seem to be saying it's not legacy, and then saying that it should be
legacy? I'm confused because the documentation/enablement is so poor a
systems administrator can not currently use saned whether he is informed
or ill-informed about it's security implications.

If it has security problems, then just say it's disabled and can be
enabled thusly, report a bug upstream about it's crappness and how it
should use ssl, gpg etc. Otherwise we have a feature that sounds
dangerous (could blow up in your face) and is so difficult to set up
that setting it up looks like a big fat packaging bug.

Surely normal operation shouldn't look like a bug, regardless of how
carefully you want systems administrators to consider the security of
their system?

Martin,

On Tue, 2011-10-25 at 17:57 +0200, Julien BLACHE wrote:
> Pretty much the only safe and correct use case that exists for saned
> is
> within LTSP (and local use for scanners that can't be used as user,
> like
> some parallel port scanners).
> 
> And even then, data is sent unencrypted so it is not suitable for use
> with sensitive documents.
> 
> If you really want to share a scanner, the correct solution is scan &
> send (either mail or private network share), not saned. Most of the
> time
> you'll just end up using an old workstation and have users log into
> it,
> scan their documents and save them to their network share.
> 
>