Agreements about the continuation of the repair feature:
2 Likes
Quick sketch about how the “double starred” epochs enable transition of data forward without preventing reverts to prior revision:
snapd must ensure that once a revision lacking a double starred epoch is installed, the double star behavior is disabled and going back an epoch is not possible anymore, even if a revert into the double starred revision happens. This is necessary because the double star is what tells the system that compatibility is still being preserved.
Agreements about the upcoming improvements for the kernel and gadget snaps that will enable image resources to be updated (top) and avoid the need of lockstep updates in the Raspberry Pi (bottom).
Agreements about how the management of textual information (summary, description, translations, etc) will take place between snapcraft and store:
Regarding the metadata/textual info, I think we also need a snapcraft command to sync from the store to the local snapcraft.yaml. So if you are a developer of a snap where the text is always edited in the store UI (possible a different person in your team), you can do something like snapcraft update-text --from-store && snapcraft && snapcraft push in your CI to ensure that builds always have the latest info inside the snap.
You would also want to periodically update the snapcraft.yaml and commit to your repo, but that could be just part of your local dev workflow.
There seems to be a contradiction between:
“If grade is unspecified in snapcraft.yaml, leave out of snap.yaml”
and
“Store should reject if grade unspecified”
Can you clarify? Is grade is now specified via some other means?
Great, wasn’t the only one to notice. I basically read this as new snaps will be rejected by default.
Adding a bit more questions:
- Are translations going to be contemplated in
snapcraft.yaml/snap.yaml? - Is the meta data going to not be part of snap.yaml?
1 Like
Out of interest, was there any discussion about using polkit here? If it is acceptable for snapd to (optionally) talk to D-Bus, then I think this would be possible and not interfere with the existing authentication system.
Here’s a quick sketch of how it could work:
- when incoming connections are made to the REST port, record the peer’s pid in the same way their uid is currently recorded.
- When processing a request, check the request headers for
Authorization: polkit. - If the request requires superuser privileges and polkit authorization has been requested, call polkitd’s
CheckAuthorizationD-Bus method with the peer’s pid and an action ID derived from the REST API request. If polkitd grants permission, allow the request to complete.
Connecting to the system bus could be delayed until this mode is requested, and it shouldn’t be too difficult to reconnect to the bus if it has been restarted since the last polkit request.
@jdstrand @sergiusens That’s indeed the intended (or at least agreed) outcome. The option was deprecated a long time ago, and right now we have snapcraft injecting “grade: stable” in snap.yaml, which is the worst of all possibilities since we lose the knowledge of what the person said completely. It’s time to start rejecting snaps that don’t specify grade. We won’t make snapcraft refuse to produce them, as that would be a breaking change, but the store may refuse to take them in.
With that said, I suggest we phase the feature in so we can anticipate the consequences: first thing is to get snapcraft to not inject the option, and then make the store accept them. This will give us visibility on what will be rejected next. Then we can start to reject them and ask for grade to be specified on the way into the store.
No, this will be in separate files, perhaps meta/i18n/<lang>.yaml. Format to be defined still.
Packing it in snap.yaml / snapcraft.yaml would make it messy and hard to collaborate on.
I don’t see how the second question is different from the first one, though.
@jamesh Not in the sprint, but we did talk about it a very long time ago, and there was even a PR for it.
The main issue with supporting polkit is that it doesn’t actually solve the problem, I think. Even if we implement support for it, we still need to be able to tell which user that is so that the store may allow access to their personal snaps, and paid content they’ve previously purchased. So polkit would need to happen in addition to the macaroon-based authentication, in which case why not solving both problems with a single mechanism?
2 Likes
The second question was related to having the store carry the information instead of the snap for the sake of one source for information clarity we need.
Regardless, I hope these make their way into more detailed forum posts as it will be hard to discuss over a bullet point since I don’t have full context of the background of each and what led to them.
2 Likes
@noise @sergiusens That’s a nice improvement, but note that snapd will already use that information from the store even if you are offline, as long as it was installed or refreshed from the store.
Also, we’re proposing to support a general mechanism for importing such metadata from third party formats such as appstream, setup.py, etc. We probably won’t implement mechanisms to feed the metadata back into these.
Still, being able to feed edits back into the snap eventually (probably explicitly rather than automatically) is handy indeed.
3 posts were split to a new topic: Should we use polkit for local auth
Why is grade used at all? How is it useful? Looks like unnecessary cruft to me…
@sergiusens - what is the status of this? Trying to figure out if there is anything to do with the review tools for this right now (and what that would be :).
Well, I have not implemented any of this as it would be rejected by the store, but if you are ready I am too.