public pulling

[adelavega]

Another question:

Is public pulling without auth on the client possible?

When I try to pull the container associated with this repo I get this error:

FATAL:   While pulling image from oci registry: error fetching image to cache: failed to get checksum for oras://ghcr.io/singularityhub/github-ci:latest: while resolving reference: failed to authorize: failed to fetch oauth token: unexpected status: 403 Forbidden

If I login to to github using a PAK, it works.

[vsoch]

I think it might be backwards - if you are authenticated with credentials and the container doesn't require it, it won't work. I think we opened an issue about this: sylabs/singularity#212

[adelavega]

Ah, I see. Maybe I didn't properly clear my token when trying. Actually I did the same thing which was cancelling the PAK. I'll keep on eye on that issue, but as long as unauthenticated users can pull my packages, I'm happy :)

[vsoch]

Can you double check that it's public? I don't see it:

[adelavega]

So 1) I think my issue was that due to a bug, I couldn't "logout", so that confused me w.r.t to public pulling of this package: sylabs/singularity#214

2. I do believe my package is currently internal and I'm not sure how to change it to public. It seems to have defaulted to internal.

[adelavega]

Okay, got it. You should be able to see it now.

I suppose as far as this example is concerned what might be relevant is to point out that packages should be public if that's the intention, and clarifying what it may default to (internal, in my case)

[vsoch]

Ah, so I think that might be an org setting. Under settings for the org there should be a packages menu, and under there you can select what level of access to give org members for packages (I think default is internal).

[vsoch]

And your analysis makes sense - I would post a note on both singularity issues to say "plus 1! This was an issue for me too!" so they are better looked at.

[adelavega]

I see. I have all 3 (public/private/internal) checked, so maybe if internal is allowed it defaults to it when creating it. Or perhaps that differs based on whether the package is created by a PAK or GITHUB_TOKEN in a ci action.