My display name in the store hasn't updated to match configured display name

[lucyllewy]

I’ve triggered a build (hopefully) for supertuxkart by pushing an empty commit to the default branch that should send a webhook to snapcraft.io.

I also have at least one saved credential that I can recall creating - specifically for building and releasing openra via github actions - If this build doesn’t cause any data issues then I’ll happily run a build in Github actions for openra to see if it’s saved credentials there that are the issue.

Although, IMO, if the credentials used to publish to the store via snapcraft tooling are causing the data to update then that is a mistake in coding of the store. I would posit that the ONLY time the data about a user is updated should be if they change it on the SSO backend, or change it directly via the store pages - simply using an API for unrelated purposes with an existing session or macaroon should not be used to update user details, unless those details are refreshed from non-user input - i.e. from the SSO backend directly, not whatever happens to be saved in their macaroon.

Sessions and macaroons should only be used for authorization and not for storing details about the user that are then used to fill the database without verifying that they are current/correct by querying the SSO backend.

EDIT: the build is completed.

EDIT 2: it looks like that did indeed screw up my name again!

[roadmr]

Thanks! I can confirm the data is borked on my side as well.

@lucyllewy

if the credentials used to publish to the store via snapcraft tooling are causing the data to update then that is a mistake in coding of the store

There’s probably some historical reason behind this logic but I can’t fathom what it would be. I concur this behavior sounds erroneous. With more concrete info (thanks to you!) I’'ve filed a bug on our side.

Do you by chance have a link to the Launchpad build in question for supertuxcart?

Oh and also, if it wasn’t apparent, a workaround while we fix this is likely to be for you to regenerate any saved build credentials: disconnect any repos from which you’re building to nuke the old credentials, do the necessary dance so that dashboard.snapcraft.io shows the correct info, and then reconnect the repositories.

Thanks again for the help figuring this out and sorry it took so long

• Daniel

[lucyllewy]

The commit triggered these builds:

• amd64
• i386
• armhf
• arm64
• ppc64el
• s390x

It looks like they finished in the order (left is the first to complete, right the last): amd64, i386, s390x, ppc64el, armhf, arm64

[lofidevops]

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.

[lucyllewy]

@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)

[roadmr]

Hi!

@lucyllewy

there needs to be a way for me to handle this in a sane way with as little effort as possible.

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).

• Daniel

[lucyllewy]

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.

[roadmr]

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

• Daniel

[lucyllewy]

@roadmr

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)

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.

[lofidevops]

Hello again @lucyllewy ! I believe the issue should now be resolved. You should now be able to:

1. Sign out of Snapcraft
2. Sign out of Ubuntu SSO
3. Purge cookies and cache, just to be sure
4. Sign into Snapcraft (implicitly signs you into Ubuntu SSO)
5. For each existing snap:
   • visit the listing page
   • if it doesn’t already show your current publisher name, hit refresh and it will (eventually) update
6. Push an update to GitHub, this will trigger a new build using your pre-existing macaroon
7. Visit the updated snap page
   • confirm that the NEW version appears, but your CURRENT publisher name remains

Notes:

• it can sometimes take 2-5 minutes for the page to update
• you can also preview the listing page

Please confirm if this resolves the issue.

[lucyllewy]

Thank you. I’ll do it shortly and report back.

[roadmr]

@lofidevops

it can sometimes take 2-5 minutes for the page to update

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"

• Daniel

[lucyllewy]

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.

[lofidevops]

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.

[lucyllewy]

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

[roadmr]

Hi! We have not forgotten, David has been working continuously to narrow down and fix the problem, we should have something concrete soon.

• Daniel

[lofidevops]

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.

[lucyllewy]

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:

1. Check the makemkv snap is currently correct:

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"
}

2. Trigger build of makemkv
3. Recheck the name on makemkv once build is completed

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.

[roadmr]

WOOHOOOOOOOOOOO!!!

David kept plugging at this for the past few weeks, I’m happy to give him all the credit on our side.

• Daniel

[lucyllewy]

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!