The commit triggered these builds:
It looks like they finished in the order (left is the first to complete, right the last): amd64, i386, s390x, ppc64el, armhf, arm64
The commit triggered these builds:
It looks like they finished in the order (left is the first to complete, right the last): amd64, i386, s390x, ppc64el, armhf, arm64
Hello @lucyllewy
Thanks for your patience. We support āpure macaroonā use cases to allow IdPs other than Ubuntu SSO via an identity manager/multiplexer. The existing behavior accommodates this, since the store doesnāt directly speak to the IdP, and so we must consider the user details data in the macaroon authoritative.
However, you wonāt be the only publisher changing their individual or company name, so we realize that we need to update our docs, explaining that you need to update macaroons if your developer info changes. Weāll leave a link here as soon as thatās done.
@lofidevops As someone who has many Snaps associated with my name, there needs to be a way for me to handle this in a sane way with as little effort as possible. For example, it seems that every snap that I build via the build service from GitHub web hooks that are automatically set up with the build service will have its own macaroon configured. Changing these individually will take a long time and expend a lot of effort (beyond the extreme effort @roadmr and I have already expended trying to understand the issue in the first place).
Also, as the name is configurable in the Snapcraft.io admin area (IIRC - if it isnāt then it should be) why are we using the macaroon for details in the first place when we can simply use whatever the authorised person configured on the site? (Edit: I just checked - it isnāt configurable directly on snapcraft.io right now - the edit details link takes you to login.ubuntu.com to change your details there)
Hi!
I appreciate this is awkward since it means one must hunt down all the tokens/macaroons with outdated information, as you observed.
The procedure recommended by the Launchpad folks is to ensure your Ubuntu SSO details are correct in https://login.ubuntu.com, then go to https://launchpad.net/~/+snaps, then for each snap, open it, and check on the right-hand side menu for a āReauthorize store uploadsā option. Click on that and it will take you through Ubuntu SSO, obtain a new macaroon with the new information, and send you back to Launchpad.
The ones that say āAuthorize Store Uploadsā probably donāt need to be touched as those would be new authorizations and are not likely to be affected by the stale macaroons thing.
For the reasons David explained (and which both him and I spent a while tracking down and reasoning about, after you helped us pinpoint what was triggering the outdated updates) itās not obvious to us how to provide a way of updating the information that bypasses those macaroons that may exist in the wild - since there was actually explicit work done to enable updating publisher info from the tokens/macaroons and pave the way for third-party IdPs with which dashboard.snapcraft.io doesnāt have privileged access (like it does for login.ubuntu.com).
To try to reduce the amount of work, I checked if there was any way to save some work by issuing a single macaroon and using that globally; however, the macaroons used for Launchpad build are package-restricted and each can only push updates for the snap they were designated for.
Your recollection that this used to be updatable in snapcraft.io and dashboard is correct; however, as you just noticed, that was modified in favor of letting the identity provider be the authoritative source for that information.
Finally let me say that it has been recognized for a while that updating publisher details is clunky for the reason explained here and generally (the ādanceā required to log in and out several times, then back in, and waving talismans around a campfire on an appropriate date as an example); we did and do have an outstanding item to improve that experience which I need to dig up and see how we can move it forward while also improving the experience when it comes to macaroon-initiated identity information updates.
Weāll keep looking at this on our side in case we can come up with ways to make this better (less likely to reoccur, and easier to recover from if it does, given that we do want macaroon information to propagate into the store).
Iāve only got one snap built through launchpad directly (gimp
's preview track - Iāve just reauthorised that one at least), so that is the only snap listed on https://launchpad.net/~/+snaps. I have one snap that I recall setting up external builds (opera
via snapcraft export-login
built on GitHub Actions) Everything else is built by snapcraft.io using web hooks that it sets up automatically with no involvement from the developer other than logging into GitHub via the snapcraft.io integration to set up automated builds - I have no clue how to update the macaroons there.
Hi -
Thatās interesting because the snapcraft.io build integration uses Launchpad under the hood; so I would have expected those recipes to be visible in your snaps page. Let me ask around to see how to reauthorize those builds.
For the github one with an exported token, the way to go is to create another token with snapcraft export-login
, but that only covers one of the builds.
Meanwhile, we are having a deeper look at the code to see if we can, via some clever logic, not update publisher information from the macaroon if we detect a more recent update (macaroons should have an issue timestamp so we can compare that with the timestamp of last update we have in the database). Iāll let you know if that pans out.
Thanks for bearing with us, weāll get this ultimately resolved
That sounds like a sensible middle-ground way that allows you to continue to use the macaroons as an authoritative source for user information beyond authorisation while only updating if the data in the macroon is newer than the data you already have - that should also allow a simple logout and login dance via the web to fix any changed data from the ID Provider without having to regenerate any other tokens.
Hello again @lucyllewy ! I believe the issue should now be resolved. You should now be able to:
Notes:
Please confirm if this resolves the issue.
Thank you. Iāll do it shortly and report back.
This happens because the web front-end does a ton of caching, you can see what the API thinks about a publisherās name and that should update instantly:
$ curl "https://api.snapcraft.io/v2/snaps/info/makemkv" -s -H "Snap-Device-Series: 16" | jq '.snap.publisher."display-name"'
"Dani Llewellyn"
Hiya, I logged out of snapcraft, deleted all cookies for snapcraft.io. Then I did the same at login.ubuntu.com. Finally, I closed the snapcraft.io tab in my browser and opened a new one and logged back into snapcraft.io. I left it for 5 minutes and verified that the listings had updated to my correct name. I then initiated a build for MakeMKV via an empty commit to the GitHub repo. Now that build has completed it looks like MakeMKV has reverted to the wrong name again.
Wut!? My immediate suspicion is that your macaroon was generated without an expiry date, but I will first repeat testing on my side.
Just to set expectations, I donāt think we will see a solution until into the new year. Iām really sorry about that.
Hiya,
Iād just like to ping this to make sure it hasnāt slipped off the radar (I doubt it has, but wanted to be sure )
I really appreciate everyoneās hard work on working on a solution to this issue, even though itās still a problem at the moment
Hi! We have not forgotten, David has been working continuously to narrow down and fix the problem, we should have something concrete soon.
Hello @lucyllewy - do you mind testing the issue again? I believe it should finally be resolved.
The short instructions remain the same.
If they donāt work (and you have the time), please follow the testing steps in How to change your publisher name and let me know at what point the name reverts.
ok, here we go - using makemkv because Iāve shown above that building that has in the past triggered my name to revert so we can assume it would do so again if the problem still exists:
curl "https://api.snapcraft.io/v2/snaps/info/makemkv" -s -H "Snap-Device-Series: 16" | jq '.snap.publisher'
{
"display-name": "Dani Llewellyn",
"id": "oew2TZOpQF0lGd3JKNZydA2BCn1Z66FO",
"username": "diddledani",
"validation": "starred"
}
curl "https://api.snapcraft.io/v2/snaps/info/makemkv" -s -H "Snap-Device-Series: 16" | jq '.snap.publisher'
{
"display-name": "Dani Llewellyn",
"id": "oew2TZOpQF0lGd3JKNZydA2BCn1Z66FO",
"username": "diddledani",
"validation": "starred"
}
I think we can tentatively say this has been fixedā¦ I hope. Thank you so much everyone for your persistence in getting this pinned down.
WOOHOOOOOOOOOOO!!!
David kept plugging at this for the past few weeks, Iām happy to give him all the credit on our side.
Thank you so much, David!
As an aside, this actually fixes a potential GDPR issue - if someone is using their legal name, and changes it like I did, then they could file a data rectification claim that would be impossible to comply with before this fix was implemented. Good job, David, in mitigating that potential legal minefield!