Good catch, this also applies to internal repositories :)

Hey @kjgstarr, apologies for the late reply! The main customers for this is ourselves (our own organisation). We have product translation workflows set up in various Github repositories that heavily relied on screenshots uploaded in pull requests to provide context to translators. This is now not possible anymore as we're unable to programmatically retrieve these screenshots anymore through our custom Github actions.

essentially the same issue in our org - deltatre-vxp

As a workaround; fetch the body of the item (so the markdown) and let that be processed by the API (as shown in my other comment: https://github.com/orgs/community/discussions/54551#discussioncomment-6730698)
That gives you URLs that have a JWT on them. Those you can fetch and do something with.

are you saying you think this also works for those who have SSO/MFA set up @mivano? can't remember what I have tried now but all the workarounds on this discussion I tried failed for me for this reason

I have a SaaS product that allows externals to send emails to an address and get those converted into discussions, and then you can reply from within the discussion with a comment including a special command to reply back via email.

Before this change, this worked great with images and attachments as they were publicly available.

After this change, I now use my GitHub app registration to call the convert markdown API, extract the URLs (which are then publicly available for 5 minutes due to the JWT) and attach them to the email (replacing the URLs with cid: references to the inline attachments).

This works great for images, not for anything else though! So e.g. a PDF does not get the converted temp public URL.

The github app registration makes the call, so no SSO/MFA issues there (but you do need the app installed and get a token).

Hope this helps

Thanks for looking into this. We are using a private repository for code and releases. Then our servers are reacting on webhooks and fetch release information on changes - including images to server them to our application. We do copy release notes including URLs and serve them as public information.

I see. Thanks for the details. Let me first acknowledge again that we broke your flow. The old behavior was a bug, but it was a load-bearing bug here.

Copying rendered content from a private repo into a public repo won't work anymore (as you discovered – I'm stating it for anyone else following along). We don't have plans to make individual components of a repo public or non-public. The same as you can't make issues public but wikis private, for example, we don't want to allow assets to be public while everything else is private.

The simplest fix without changing everything else is probably to host images someplace else, such as your own cloud storage bucket, and link them using ![title](https://example.com/url/to/image.png) syntax instead of using drag-and-drop/copy-paste.

ok @vtbassmatt - thanks for the clarification - we will think about the best way to fix it on our end. Today we hosted them outside of GitHub and used the URLs, but it requires some extra work.

@vtbassmatt
We have exactly the same problem. We get an in app. release notes from a private repository using octokit.net and markdig.
And now all images are unavailable :(
Uploading images to third-party hosting, of course, will complicate things a lot :(

Thank you, I've tracked that issue and will make sure it gets routed to the owning team.

Confirmed that the tokens generated by Actions don't have access. You'll need an OAuth token with user and repo scopes, probably stored as a repository secret that your workflow can access. I'm taking a note to see if we can improve this in the future.

Thank you for the useful info!
By saying OAutj token you mean a personal token? (https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token#creating-a-fine-grained-personal-access-token ?)
Any chance you / some1 is familiar with the process of generating such a token ?

for posterity - verified - creating PAT with user & repo permissions does the trick. Tnx for the help @vtbassmatt 🙏

Yes, a PAT will work here too. Thanks!

for posterity 2.0 - we've added this code to our workflow. when we parse the PR's description we take the images and instead of attaching their link to the notification we upload the image to our storage (at this case to cloudflare but feel free to replace it with your provider)

async function uploadImageToCloudflare(imageUrl) {
    const f = new FormData();

    f.append('url', imageUrl);

    const cloudflareUrl = await fetch(`https://api.cloudflare.com/client/v4/accounts/${env.CLOUDFLARE_ENV}/images/v1`, {
        method: 'POST',
        headers: {
            Authorization: `Bearer ${env.CLOUDFLARE_TOKEN}`,
        },
        body: f,
    });

    const json = await cloudflareUrl.json();

    return json.result.variants[0];
}

const getImageUrl = async (originalUrl) => {
    try {
        const res = await fetch(originalUrl, {
            redirect: 'manual',
            headers: {
                Authorization: `token ${env.NOW_IN_PRODUCTION_TOKEN}`,
            },
            method: 'GET',
        });

        return res.headers.get('location') ? uploadImageToCloudflare(res.headers.get('location')) : '';
    } catch (e) {
        console.log(e);
    }
    return '';
};

Thanks @orthopteroid. Glad to have confirmation of what's happening here. We've got a tracking issue to figure out something better, probably with a bit of client-side JavaScript to paper over the short timeout. (The timeout is that short because we needed to find a balance between long enough to do work but short enough to remain reasonably secure. I'm not saying we nailed it with 5 minutes, but it was a reasonable starting point.)

I'm a bit confused here. Why can't the image be returned (or not) based on the existing authentication tokens in the browser? Why does there need to be a short lived token on the URL?

If that was the case you could not be able to send the link to non authenticated users @daviewales

But isn't that the point of this whole thread?

Now, future attachments associated with private repositories can only be viewed after logging in.

I don't know what was the exact ER.

I can only say that from my personal POV that there are cases where we want to share / show an image to non logged in users (e.g non technical peers at the company who don't have github account).

The ability to get a short term link enables me to send this link without the need of downloading the image or to share credentials with others.

Can you use a public repo for sharing files/images which you intend other people to see?

The usecase I'm describing is sharing media attached to PRs in a standard corporate monorepo, which has to be private for obvious reasons.

While the obfuscation was considerable given the length of the URL, it was very easy for users to post highly confidential information as github images without being aware they were placing that information into the public domain.

There are many summary charts that are in-and-of-themselves a severe breach of data confidentiality and placing them behind a security layer that was merely "fingers crossed no-one finds it" was (probably) always a huge violation of SOC2 & GDPR.

The change has its annoyances, but allowing secure info to be trivially made insecure is so antipattern to best practice that it should not be allowed to continue as the default.

That said, allowing repo admins to choose the security model of attached images would be very welcome.

While the obfuscation considerable given the length of the URL, it was very easy for users to post highly confidential information as github images without being aware they were placing that information into the public domain.

There are many summary charts that are in-and-of-themselves a severe breach of data confidentiality and placing them behind a security layer that was merely "fingers crossed no-one finds it" was (probably) always a huge violation of SOC2.

The change has its annoyances, but allowing secure info to be trivially made insecure is so antipattern to best practice that it should not be allowed to continue as the default.

That said, allowing repo admins to choose the security model of attached images would be very welcome.

maybe a revokable jwt for public sharing?

Today, you can either let GitHub render the whole body (which will give you <img> tags complete with 5-minute-limited active attachment links) or you can scrape the asset URLs out of the raw Markdown as mentioned in that comment. In the future, we hope to introduce an API endpoint specific to assets, and we have an internal issue tracking the feature.

Thanks for this tip. For reference, you can do a call like this:

gh api 
-H "Accept: application/vnd.github+json" 
-H "X-GitHub-Api-Version: 2022-11-28" 
--method POST 
/markdown  
-f text="lets send something with an image in it.\r\n<img width=\"1297\" alt=\"Screenshot 2023-08-13 at 23 00 50\" src=\"https://github.com/org/repo/assets/668535/5c3a4439-40e3-4868-8bf5-1069efef670e\">\r\nand a pdf\r\n[3689119.pdf](https://github.com/org/repo/files/12339127/3689119.pdf)\r\n" 
-f context="org/repo" 
-f mode="gfm"

Which will return a text with links to https://private-user-images.githubusercontent.com combined with a JWT, which can be accessed directly.

The trick is to use context and mode; otherwise, you get the original contents back. See the docs

Be aware that there is a difference between images (in /assets) and in attachments (in /files). Only the assets get converted.

I still prefer a more explicit API endpoint to retrieve (and preferably even add) attachments to issues/comments/discussions).

I just want to add here as well that you do need (for a GitHub App) Contents permission. Although the markdown call will work without it, it will not convert the images to the accessible url. I think you need a similar PAT with repo scope access if you go that route.

Setting the Contents is something I rather not do, as it contains a lot, although I can imagine why the markdown endpoint needs it (it will also replace issue ids to links etc). I tried the Single Path option, but no luck there.

The most sensible solution for me would be an endpoint to access the attachments. Like an attachable to the Discussion which allows us to retrieve the attachments. Preferable even storage.

How would they know what is unintended if we do not have a way to browse the uploaded images?

You would need to identify the attachments you want removed.

At least one customer I'm aware of wrote a private tool using the REST API to identify and browse all attachments in their organization. Conceptually it was something like:

for repo in org:
    for issue in repo:
        fetch issue body
        grep for strings like "\s!\[.*\]\(\S*\)\s"  # \s is any whitespace; \S is any non-whitespace
        report repo, issue number, and each string found

        for comment in issue:
            fetch/grep/report

    for PR in repo:
        fetch/grep/report

        for comment in PR:
            fetch/grep/report

Yeah, that's possible for images still referenced from issues etc. But sensitive information that was auto-uploaded by mistake are still saved on GH's servers without us having a way to identify the paths.

I agree, those attachments no longer discoverable or recoverable. But by the same token, no one else can find them either. Ideally, there'd be a way to purge unreferenced content. In practice, the return would be small whereas the work required is large. (It's something I'll investigate in case I'm wrong, though.)

There's probably a small risk of malicious actors smuggling sensitive data out this way. But then why wouldn't they smuggle the same data out through some less-complicated means, like direct to an image hosting site or a cloud blob store?

Yes, the risk is small but the consequences of a breach are potentially large. And since the problem persist the potential consequences increase over time.
In a security or GDPR audit that risk needs to be addressed—either by GitHub doing the required work to fix the it (enabling their customers to audit and remove uploads) or by all their customers describing the problem and accepting the risk. Given the number of customers I guess the total work of the first is relatively small compared to the second...

How is this related to the subject of this thread?

Its a bug with the new feature announced in this thread "More secure private attachments".

How is this related to the subject of this thread?

How is it not?

specifically. We can't find a way to fetch an attached image - the workaround from this discussion does not work seemingly due SSO log and/or MFA

we need a supported "get repo attachment" API

Could you suggest solution to the problem with SSO login which appeared after introduction of subject of this topic 'private domain' for images.

How is this related to the subject of this thread?

Sorry, this solution does not work

[W]ith a paid organization, is there any retention period on the assets?

There is not.

In which circumstances the assets may be deleted by GitHub?

The main one that a typical customer should know about is: deleting the repository will cause the assets to be deleted. Rarely, remedying various forms of abuse might require deleting the asset.

What are the storage limits (not individual assets, but total)?

I don't think we've published any limits on this type of storage.

What happens when the repository is moved or deleted (assuming the asset was uploaded in one of the comments)?

As mentioned above, deleting the repository will delete the assets (eventually – there is a built-in delay to many of our post-delete cleanup jobs). Moving the repository will logically "reparent" the assets to the new ownership.

What if the user that uploaded the asset is removed from the organization, does that affect anything?

Once uploaded, assets are tied to the repository, not the user who added them. So removing the user would not affect the assets.

@vtbassmatt great info! For completeness, would you mind also covering what happens to attachments when a private repository is made public, and vice versa?

At the moment, nothing. (That is: attachments keep acting as if they were in the state the repo was in when they were created.) It's a gap the team intends to address over time.

Also, I will note that I've moved on from this area of GitHub so my knowledge will rapidly decay 😅 @kjgstarr is the product manager for this area now.