Inkscape autoconnect cups-control

[ted]

@kyrofa

seems about as political a decision as not wanting to break backwards compatibility in an API.

Not really, an API doesn’t choose which applications can use it or not. Here we’d be avoiding breaking applications that have the phone number of management.

@kyrofa

I’m indeed a developer inasmuch as I write software

You’re right, it doesn’t matter whether any of us are developers are not, I was incorrect to state that. There shouldn’t be any anecdotes involved in voting. It shouldn’t be about personal experience but about user experiences.

@kyrofa

The question is whether the application would appear fundamentally broken without the functionality

I’d say it is whether a project would feel like they need to put on the download page “here’s how snaps are broken” with a discussion of it. It is at that level for Inkscape. Inkscape Snap Download Page.

@jdstrand

Arguing that ‘cups-control’ is all we have is one thing, but arguing that auto-connecting cups-control is all we have is quite another and I disagree

I would argue given the current state of the UI controls it either auto-connects or it doesn’t exist. Frankly, I was surprised I had to make this forum post I figured the issue was something wrong with my snap. It didn’t occur to me that I can autoconnect to X11 but not CUPS.

@jdstrand

the vote is for auto-connecting cups-control, then we should reapply that new criteria to the gimp for consistency.

I would support autoconnecting cups-control for The GIMP as well. I think you’d have a hard time defining which apps are comparable to others.

[alexmurray]

We autoconnect desktop / x11 which we know have shortcomings from a confinement point of view, but we do this for convenience / usability until better interfaces (security-wise) are ready - why not apply the same logic for cups-control but with a strong encouragement (documentation-wise) to avoid it and instead promote portals as the preferred mechanism (for apps which can support it) and then take @jamesh idea to add polkit authentication to CUPS or similar so we can feel more confident in granting cups-control for situations like this?

[sergiusens]

@jdstrand

Manual connection makes sense to me. Contrast that to chromium where people fill out forms, etc and are constantly told to print the confirmation.

Is this anecdotal? I have never printed from chromium or firefox but print from evince instead (yes, anecdotal).

[sergiusens]

General hooks (configure, refresh, install) run under their own confinement, do they not? Not sure about the interface hook, but it would need to run under the confinement of the connecting plug specific to the application for the snapctl check to be a good one.

[jdstrand]

@sergiusens

Is this anecdotal? I have never printed from chromium or firefox but print from evince instead (yes, anecdotal).

Firefox and chrome have an internal pdf viewer and don’t rely on evince/some other mime handler. The same appears to be true for firefox with general printing.

[jdstrand]

@alexmurray

We autoconnect desktop / x11 which we know have shortcomings from a confinement point of view, but we do this for convenience / usability until better interfaces (security-wise) are ready - why not apply the same logic for cups-control but with a strong encouragement (documentation-wise) to avoid it and instead promote portals as the preferred mechanism (for apps which can support it) and then take @jamesh idea to add polkit authentication to CUPS or similar so we can feel more confident in granting cups-control for situations like this?

Because with desktop/x11 most applications completely fail to work if these aren’t connected. With printing, most applications typically can work fine without it until one tries to print but even then application is in a position to guide the user. To me, we should not change the base declaration to auto-connect cups-control, but we should have a consistent voting policy on when to grant auto-connection.

I’m all for having documentation for encouraging people to use blessed APIs. TBH, I’m a bit surprised that polkit wasn’t upstreamed in cupsd already. There is cups-pk-helper, but AIUI, that is about exposing non-cups DBus APIs and using that service as a proxy so the application doesn’t have to use the cups socket directly. Another option would be to use a proxy service. I suspect that this could be fairly simple since cups has a rather extensive auth and ACL mechanism. It could be that a service snapd provides that runs as non-root and non-admin (from a cupsd PoV) listens on a socket. That socket is bind mounted into the the snap’s runtime at the normal cupsd socket location. Snaps connect to it and then the service proxies everything between the snap and the real cupsd socket. Because the user the proxy runs under has no special permissions for configuring printers, etc, it is only allowed to print. We would need another snapd interface to trigger this bind mount behavior whereas cups-control would not trigger it.

[jdstrand]

@jdstrand

I’m asking all @reviewers to review all of this topic so we can come to a consensus and have clear voting standards on this interface. @niemeyer and @pedronis, can you weigh in as well?

Ping, if you haven’t already responded, please do so. We need to come to an agreement on clearer criteria for this interface.

[jdstrand]

@jdstrand

I’m asking all @reviewers to review all of this topic so we can come to a consensus and have clear voting standards on this interface. @niemeyer and @pedronis, can you weigh in as well?

Ping, if you haven’t already responded, please do so. We need to come to an agreement on clearer criteria for this interface.

Still haven’t heard anything since this last ping.

[mcphail]

Can I add my perspective as a user? If I’m using a graphics creation tool, I might want to print out the results. That would be expected behaviour of the tool. If I have to jump through the hoop to connect the interface to enable printing, that is irritating. Furthermore, once I have done that I am no better off from a security point of view than if the interface had been automatically connected. The problem is the interface giving too much power, not the autoconnection.

I would expect to be able to print my photos from gimp, my drawings from inkscape and my boarding passes from Firefox. Why make me jump through an obscure hoop which will leave a security vulnerability anyway? It is like putting a lock on a parachute.

[jbicha]

@jdstrand

Today, right now, an application can use gtk3 and print via portals without needing a snap declaration for cups-control.

Snap doesn’t support portals yet, right (but soon!) ?

[kyrofa]

@mcphail

Why make me jump through an obscure hoop which will leave a security vulnerability anyway?

The alternative is to expose that vulnerability for everyone using the snap by default, is that what you’re advocating for?

[mcphail]

Yes. I think the user inconvenience of having to manually connect this snap for a piece of core functionality cannot be justified by the scale of the threat, when taken in the context that the snap can autoconnect the home and x11 interfaces already. Compared to other snaps in the store I am reassured that:

• the upstream can be trusted to not abuse the interface
• the snap packager can be trusted to not abuse the interface
• the cups-control interface is hard to be damaged by accident from a programming error.

On the other side of the coin:

• the program takes and processes untrusted user input. It is entirely credible that a maliciously crafted image file could compromise the program. It is conceivable there could be a chain of compromises which could abuse the cups-control interface.

But even if this was not connected the home and x11 interfaces are connected and ripe for abuse.

At present, if I install any snap from the store I’m forced to accept that it can read, write, modify or delete the majority of files in my home directory, communicate with a remote server and eavesdrop on my keyboard input to other x11 applications by default. Asking me to manually connect a printing interface for a trusted image creation application from a trusted upstream source and packager seems like rearranging the deckchairs on the Titanic. The benefits to me, as a user, are minimal in this context. I firmly believe the user convenience of autoconnecting this interface for this snap outweighs the small security risk.

[cjp256]

I’m a newcomer, but I’m going to jump in on this one

Facts:

• The <app> provides a mechanism to <action: print>.
• Snaps break this <action: print> mechanism by default.
• Non-trivial exercise for users to fix the snap’s functionality today.

Opinions:

• I expect this app to do <action: print> based on <my subjective experience of what I have done in the past or the security properties I desire in this snap>.
• I value <security|usability> over this [perceived] loss in <usability|security>.

What are the threat vectors?

• That a malicious inkscape snap will package a CUPS exploit?
• That inkscape is compromised (say via malicious image) and can then perhaps pivot with a CUPS exploit or otherwise abuse the interface?

So what are the options?

(Option 1) Auto-Connect

Usability: Win for everyone.

Security: Requires second vulnerability to break confinement (the scope of this request is the attack surface of CUPS).

(Option 2) Deny Auto-Connect

Usability: Fail for subset of users.

Security: Snap version is “secure”. Some users will switch to lesser secure options (i.e. deb and rpm packages) which may in fact harm security posture.

Another anecdotal story

I come from a background where security nearly always trumped usability. There is a real concern with security-savvy developers that prioritize security over all else, because they know how to work around it when it gets in their way. The problem is that we sometimes lose sight of the practical impacts of our decisions, which often actually reduces effective security because users will workaround the problem themselves with a way that has zero regard for security.

• Strong, hard-to-remember password complexity requirements lead to pattern passwords, post-it notes, etc.

• Will just turn off confinement altogether (see hundreds of blogs posts / HOWTOs that permanently disable SELinux for the user to perform some action in which SELinux was getting in the way, etc.)

In this case, they will turn to use a less-secure option because “it just works”. Like apt-get install inkscape. Which, ironically, likely presents a negative long-term effect on the security posture of our users if we choose Option 2.

Users install GUI snaps for convenience of using the application. Some of those users may appreciate the security benefits its packaging format provides. I think it’s up to us (the snap community) to improve security without negatively impacting usability:

• UIs to allow the user to toggle confinement options, etc.

• Run-time prompts “Do you want to allow this snap to print? [Always | This Time Only | Never]”

TL;DR

Snaps are effectively competing with more usable options. If snaps disrupt the user experience, snap adoption will suffer. Usability needs to be on-par, or as close to par as possible.

Raising the bar for security is a good thing. But there needs to be an actionable path to point towards so it can be done in manner that doesn’t negatively affect the user. If we can get that story straight, we can start declining requests without any of this contention.

[cjp256]

As a follow-up, I propose to reduce future contention in future requests by formalizing a written policy that is minimally subjective and easily repeatable. If this exists, I could not find it.

For example, to request <interface> auto-connect:

1. Is application publisher considered trusted by the Snap Store?

<instructions on how to become one>

2. Has publisher agreed that they are in accordance to with the <access control policy for authentication keys which can push to store>?

This agreement would help minimize the risk that an unauthorized user can obtain the keys to push an unauthorized <snap> version to the store. It may include consequences if it is discovered that the policy is not adhered to.

3. Does the snapcraft recipe perform a repeatable build in accordance to <version policy>?

This could be useful to automate validation of builds and provide an audit trail in case of abuse.

4. Does the requested auto-connect interface enable a feature that a reasonable user would expect to work?

That is, does the non-snap version expose this functionality to the user?

5. Are there alternatives to using the requested interface that do not impact “reasonable user” functionality?

• Are the alternative(s) documented?
• Is this request intended to be temporary?
• Has publisher agreed on path towards this implementation?
• Has publisher documented grievance on the recommended alternative approach(es)?

6. Is this application documented as a core, or security-critical snap?

Is there a documented reason to ensure this application is as hardened / locked down as possible for system security reasons? Presumably this would make the case harder to get auto-connect.

[jdstrand]

While I appreciate the added information, it hasn’t changed anything wrt my opinion. My opinion isn’t the only one of course and if you look back, I asked for an architect to get involved to potentially overturn the vote.

You provide a lot of reasonable points for usability and removing developer friction (which were acknowledged prior here and in other topics requesting cups-control), but you didn’t acknowledge the importance of the user’s voice in auto-connetions (to connect or not is dictated by snapd (the base declaration), the store (snap declaration) and the user (manually connect/disconnect) or acknowledge that this interface allows configuring printers which is beyond the scope of printing and what inkscape specifically needs. There seems to be a disconnect that this is about security trumping usability. snapd is a new system that is designed for usability, security, reliability, predictability, etc. CUPS does not currently have snap-integration such that it will allow only printing to snaps and so granting inkscape auto-connect, and by extension the ability to configure printers, might provide usability but is unexpected, which degrades security and predictability. Importantly, developers are in full control of guiding the users to provide a better user experience; inkscape is in a position to detect that the interface is not connected and tell the user what to do (indeed other snaps do exactly this), but apparently it still doesn’t do this.

If there was an interface that allowed just printing, then I would vote to auto-connect it (indeed, there is: the desktop interface that allows access to Portals). You said that snaps are competing with more usable options. You are perhaps referring to flatpak which allows access to the portal by default, not the CUPS socket. Snaps also have access to Portals and if they still aren’t working, someone should fix that.

Also keep in mind that all the reviewers attempt to consider your various points and more when voting and we attempt to be consistent and consider prior votes when voting on new snaps. The problem AFAICS with inkscape in particular is that people landed on different sides on if printing is core functionality in inkscape. There are reasonable arguments on both sides. The majority felt that it wasn’t core enough to outweigh diminishing the user’s voice and the predictability and security of the system. This vote has proved contentious so I asked architects to weigh in (cc @pedronis and @niemeyer).

There are many paths forward:

• inkscape could immediately improve the experience and detect if the resource is available and guide the user to the snap-store GUI or terminal command, like other snaps do
• an architect could overrule the vote and grant a snap declaration to inkscape for cups-control
• snapd could make it easier for snaps to detect if interfaces are connected
• snapd could provide APIs for the application to request a connection prompt
• the printing portal should be made to work if it still isn’t available, and inkscape to use it
• snapd/the system could provide a contextual prompt when the cups socket is accessed
• CUPS could be modified to be made snap-aware (eg, only allow printing if a new ‘cups-print’ interface is connected)

[jdstrand]

@cjp256

As a follow-up, I propose to reduce future contention in future requests by formalizing a written policy that is minimally subjective and easily repeatable. If this exists, I could not find it.

There is Process for aliases, auto-connections and tracks which discusses the procedure. Unlike with classic and base snaps which have formalized criteria, interface auto-connections are not codified because each request is unique and subjective and we want to maintain flexibility for change and new thought. That said, all the reviewers consider prior votes for similar requests which can be shown through forum research.

[cjp256]

Great points, thank you for sharing Jamie ! Very informative.

As far as other “more usable options”, I wasn’t quite narrowly suggesting flatpaks. I’m inclusive of any option for a user to obtain their software, but the bar is probably best set by the OS’ native packages (In Ubuntu’s case, the debs from the apt mirrors). If it works in the apt repositories, a user would (rightfully) expect it to work as a snap, particularly if the software center prioritizes the snap version over that found in the apt repositories.

As you suggest, there plenty of routes in which things may be improved. There has clearly been an incredible amount of amazing work done by the snap community to get usability as great as it is, across a massive range of projects. It truly is impressive. I’m personally advocating that if none of the technical solutions are immediately available in this case, perhaps we work with the inkscape community to find the optimal path for all parties going forward. In the meantime, an auto-connect does not seem unreasonable given the alternative (frustrated users, perhaps ending up using a wholly unconfined deb, and perhaps worse yet: apt remove gnome-software-plugin-snap or whatever post they come across on how to disable snaps).

I don’t think anyone here wants to see negative community feedback associated with snap packages breaking expected application behavior. If they decide that snaps aren’t worth the hassle, they’ll resort to another option. I know I have spent plenty of hours debugging why certain snaps aren’t working as intended - I don’t think that’s fair to expect that of our users (even if it’s just one short google search away)! Especially when we have a viable option on the table.

Anyways, enough from me. Have a great weekend!

[karl]

I read about 40% through this useless argument page. I abandoned Corel Draw and my VirtualBox running Windows 7 so that I could switch to Inkscape. When I started seeing how versatile Snap was I decided to install it on my new laptop using Snap. After weeks of scratching trying to get printing working, and finally coming to this page, I have decided that the people who make the decisions don’t care about the needs of the people who actually use the product.

I will revert back to install Inkscape the old fashioned way, and will slowly migrate ALL my apps back to the old APT system, which never failed me.

My work centers around designing stuff, then printing it to show the partners and get approval. Now I have to print to a pdf, then open the pdf in another app just so I can print it, and if I find anything wrong with the output product, I have to do it all again… it’s like slavery with an extra step.

In the words of Cartman “S**** you guys, I’m going home!”

[pedronis]

@jdstrand

snapd could make it easier for snaps to detect if interfaces are connected

we have now plans to implement snapctl is-connected PLUG|SLOT

@jdstrand

snapd could provide APIs for the application to request a connection prompt

we have discussed this option for later as well, it would tie into some form of “auto-connection: prompt” (not actual syntax) feature. Then the snap would have some snapctl command to prompt and possibly get the connection if the user agreed.

[sabdfl]

Hi folks. We knew when we started on sandboxing that future facilities would enable more fine-grained access control. It seems in this discussion we have made perfect the enemy of good. Giving Inkscape access to pprinting makes sense - it’s a design program, and paper copies are a normal part of the workflow there. Can I ask that we give Inkscape printing access now, while planning to offer more fine-grained facilities and saying clearly that we will expect maintainers and upstreams to do the work on their side when we have those facilities?