=== cpaelzer_ is now known as cpaelzer
=== guruprasad changed the topic of #launchpad to: Help contact: lgp171188 (05:00-13:00 UTC) | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide https://help.launchpad.net/ | Support and spam reporting: https://answers.launchpad.net/launchpad
=== JanC_ is now known as JanC
[11:38] <SergioSchvezov[m> Hi, can anyone tell me why I don't have permissions to view https://launchpad.net/~/+snaps ?
[11:50] <cjwatson> SergioSchvezov[m: do you get an OOPS by any chance?  that would help to track it down
[11:52] <cjwatson> I _think_ that the visibility filtering might not be quite right for private snaps that aren't owned by you but that are attached to branches/repositories you own.  Maybe
[11:53] <SergioSchvezov[m> I get a standard "Not allowed here" message with no OOPS
[11:55] <SergioSchvezov[m> FWIW, I am in no hurry for this
[11:55] <cjwatson> damn.  ok, could you please file a bug as I think I can see what the problem might be from code inspection?
[11:55] <cjwatson> but I'll need to do some database digging to verify that, and write a test
[12:02] <SergioSchvezov[m> logged LP: #2012379, with all the information I could grab
[12:02] -ubottu:#launchpad- Launchpad bug 2012379 in Launchpad itself "Permission denied for /~/+snaps" [Undecided, New] https://launchpad.net/bugs/2012379
[12:04] <cjwatson> SergioSchvezov[m: the relevant query is https://paste.ubuntu.com/p/p8kBqPWqCP/ if you want a sense of complexity ;-)  (fortunately we don't work on it in that form, that's after it's gone through a query compiler)
[12:06] <cjwatson> I think basically we need a Snap.owner condition in a couple more places
[12:11] <cjwatson> Hm no, the privacy filter should be enough
[12:13] <cjwatson> I think the problem is `~sergiusens/+snap/snapcraft-build1`, which is a private snap recipe using a git repository by URL with no access grants allowing anyone to see it - this may have been an old way to do private builds
[12:15] <SergioSchvezov[m> it rings a bell, it was for that one time CVE we had years ago
[12:16] <cjwatson> This may have been a bad migration - we moved to relying on explicit subscribers for access, but maybe there were few enough snap recipes in this situation that we didn't migrate them properly
[12:16] <SergioSchvezov[m> I can leave that lying around if you want to fix this and have me test; or try and remove it to verify your theory
[12:16] <cjwatson> You won't be able to see it to remove it, for the same reason
[12:16] <cjwatson> I think this is both a bad migration and a bad listing query
[12:17] <cjwatson> So we might want to figure out if there are any other snaps in the same situation first
[12:20] <cjwatson> OK, there are two, yours and a similar snapd one
[12:21] <SergioSchvezov[m> I was going to suggest mvo, as I followed the guide he created for dealing with CVEs
[16:29] <cjwatson> SergioSchvezov[m: That page should load for you now, I think (though the other part of the bug means that https://launchpad.net/~sergiusens/+snaps won't currently load for anyone else)
[19:02] <SergioSchvezov[m> works, thank you!