Hi,
The bcc snap uses the system-trace, system-observe, and mount-observe interfaces. Could we please set these to automatically connect?
These interfaces are 100% required for the bcc snap to operate and it is a reasonable request.
The only question I have is: how official is this snap and what level of maintenance can we expect? I see two bcc snaps in the store, neither in the Canonical or iovisor (ie upstream) publishers. The system-trace interface is amazingly powerful and auto-connection strongly implies vouching for the quality of the snap to the extent that anyone installing the snap can have high confidence that it will operate correctly and is well-maintained.
My team was told that the Canonical account should only be used to publish official Canonical products.
The snap is registered to my name, but I’ve made Colin King a collaborator. @cking regularly publishes QA’ed updates to the snap, about once every week or two.
Right and you are doing the right thing not uploading with the Canonical account. This gets to my point though that Canonical is not officially backing the snap which is why I asked my original question. If there is no official backing from committed developers, I’m reluctant to vouch for the snap and removing the user’s say in interface connections at install time.
Is the Canonical Kernel team committing to its maintenance?
The upstream developers are willing to update their docs to point at the snap.
It absolutely remains my goal to have them publish updates. Seeing the instructions become a simple snap install bcc would most certainly help.
1 Like
But is the Canonical Kernel team committing to its maintenance?
@niemeyer - what are your thoughts on this topic?
Process for aliases, auto-connections and tracks is now approved. It has been 1 week since the initial request, but there are outstanding questions that should be answered before people cast their votes.
@evan - is the Canonical Kernel team committing to its maintenance?
It sounds fine to me to offer the snap auto-connection. We probably shouldn’t be asking for promises of continued maintenance to auto-connect an interface, because the decision is really being made on the basis of what the current snap requires and offers, and whether we trust the person making the request to not abuse the grant for unrelated needs (patches, etc). In this specific case, the whole point of said snap is to introspect the system deeply, so it’s implicit from that stated goal that these resources need to be accessed, and we do trust the publisher, so it seems reasonable to grant access by default.
@niemeyer, I think it is important to consider the publisher of the snap (and part of that consideration is maintenance) when granting auto-connections because we as store reviewers are vouching for the publisher to the extent that we are taking away the user’s decision to connect at install time (yes, they can always disconnect). While I trust Evan to not abuse this (powerful) interface, I’m not sure that is justification for me to make that decision for all users since it isn’t clear the level of support this snap will get, it any. It seems clear that Evan himself is not committed to the maintenance (this is fine; not implying Evan should) and that makes me feel the interface shouldn’t be auto-connected. There hasn’t been a response yet from the kernel team. I’d like to hear from them before casting my vote.
At this point, more than one week has passed, so tallying votes:
1 vote for
0 votes against
0 votes abstained.
There are not enough votes at this time to grant the auto-connection. Adding the 3 day extension to the voting period (to be tallied on May 11 or after).
Directly pinging a few store reviewers to push this along: @JamieBennett, @Wimpress, @tyhicks and/or @natalia can you vote on whether to allow or deny this auto-alias?
Again, I don’t see support/maintenance as a point that should be taken into account for granting interfaces, because that’s very subjective, hard to judge in advance, and unlikely to be promised by the vast majority of contributors that will be publishing snaps. Not even I would personally be willing to vouch for support on third-party snaps that I happen to be interested on, which makes me believe that this is unreasonable to ask people for.
From a different angle, it’s also strange to decide on whether an interface should be auto-connected or not today based on the unknown future of the snap. The decision is being made today, and the snap being published today. If we get to know about vulnerabilities of the snap which affect what is published, we can very easily make a different decision and change the auto-connection setting as well in the future.
Because interfaces are manually connected for a reason, because a snap declaration granting auto-connection takes the user’s voice away at install time and because granting an auto-connection is the store vouching for the publisher, I strongly feel looking at the publisher is an important consideration.
Given that, part of my personal criteria for the health of a publisher and the appropriateness of the request is the publisher’s intent for maintenance. Your point about the unknown future of the snap is valid and for a publisher who said they planned to keep the snap up to date I fully agree and would vote to grant the declaration. If they don’t honor that promise in the unknown future, we could always revoke the declaration at some future date.
In this particular case for this particular snap, I had a feeling that the future was known: and I was right, no one has stood up to claim maintenance for the snap. Therefore if the auto-connection was already granted, there could be an argument made that it should be revoked (since the ‘upstream’ (ie, ev and/or the kernel team) have effectively abandoned the snap). That said, if someone did make that argument today, I would say it is premature since we haven’t seen ‘upstream’ not provide security updates.
As of today, I’m abstaining from this vote. I trust ‘ev’ because I know him personally but feel it would be unfair to give him preferential treatment when my criteria are not being met. I’m happy to discuss this further if needed, but I suggest that other reviewers participate in the conversation.
Today’s tally:
1 vote in favor
0 votes against
1 vote abstained
Per our processes, this is not enough to grant the auto-connection today. I previously requested other reviewers vote, but no additional votes were cast. Re-pinging to move this discussion along. @JamieBennett, @Wimpress, @tyhicks and/or @natalia can you vote on whether to allow or deny this auto-connection request?
I would be for granting this auto connection. The point by @niemeyer is most salient here, granting the connection at this time does not mean this is a final decision and given that we have no reason to believe the snap is malicious or unmaintained (this will need to be proven over time) then I see no reason to block and instead we can monitor it over time.
Retallying since we have enough votes.
2 votes for
0 votes against
1 vote abstained
Granting auto-connection. The changes are live now.
@evan I encourage you to either get upstream to maintain this snap, for you to maintain it or to work with the kernel team on maintaining it.