New macaroon caveat breaks snapcraft release process

snapcraft
1

I have a CI system that builds and releases my snaps for me whenever I create a pull request. That system has a macaroon that I generated a while back with the permission necessary to do that, with package_push and package_release ACLs. That system recently started failing to release, however:

$ snapcraft login --with creds

Login successful. You now have these capabilities:

snaps:       ['kyrofa-test-snap2']
channels:    ['edge']
permissions: ['package_push', 'package_release']
expires:     None

$ snapcraft push kyrofa-test-snap2_0.1_amd64.snap --release=edge
Preparing to push 'kyrofa-test-snap2_0.1_amd64.snap'.
After pushing, the resulting snap revision will be released to 'edge' when it passes the Snap Store review.
Running the review tools before pushing this snap to the Snap Store.
Pushing 'kyrofa-test-snap2_0.1_amd64.snap' [====================================================] 100%
Processing...|                                                                                        
released
Revision 18 of 'kyrofa-test-snap2' created.
Error fetching status of snap id 'w99x8XxPrYxC0EyBJK22RibawoEKoCJw' for 'amd64' in '16' series: Permission "package_access" is required as a macaroon caveat..

This has worked for a year now. Breaking my CI isnā€™t cool, and we document that process (including those ACLs) in a number of places. Is there any chance we can make the old ACLs continue working?

2 Likes
2

Also, package_access enforces a 1 year expiry time on the macaroon. Not a deal breaker, but one more thing for people to remember to update in their CI.

1 Like
3

Thatā€™s not a battle I was planning to fight here, but yes, I agree. Even the authorization given to Launchpad to publish my snaps expires after a year and requires a manual re-authorization once I start getting spammed with failed upload emails. A more painless CI story would be lovely.

But thatā€™s a different problem than actually changing things such that my established process breaks.

4

Which version of snapcraft are you using? There havenā€™t been store changes here recently, but the ongoing progressive releases work in snapcraft has changed the API calls that it makes.

5

3.11, latest stable snap.

6

I think the error is likely triggered by this code in _upload_snap() just after the snap is uploaded/released:

Since this is just seems to be informational, it could probably catch the exception and ignore it.

It looks like this was added in September last year here:

So Iā€™m curious what version of Snapcraft you were using previously if things only broke now.

7

Yeah I really did mean ā€œrecentlyā€ not necessarily ā€œyesterday.ā€ Itā€™s been broken for a while, I just havenā€™t had time to dig into why exactly. Iā€™ve regenerated things with the new caveat so Iā€™m back up and running, but I do suggest we be careful with this type of change in the future, and consider ways to let those old ACLs still be enough for snapcraft push --release, whatever that entails.

8

Also sounds like I should switch categories, here (done).

9

Is this going to be fixed? Implicit Travis switch to 4.1.1 had just broke my CI as well.

According to the macaroon docs there is no reason why uploader need package_access permission in addition to everything that in included in package_upload.

Another summer day with snapcraft. Good I donā€™t have a girlfriend. :smiley:

1 Like
10

4a8sbu

3 Likes
11

Need more :heart: options for Discourse. :grin: