More secure private attachments - GA

[tuves]

Previously, all attached (drag-and-dropped) images and videos on GitHub Issues, Pull Requests, Discussions, and wikis were available to view without authentication if you knew their direct URL.
Now, future attachments associated with private repositories can only be viewed after logging in.
This doesn't apply retroactively to existing attachments, which are obfuscated by having a long, unguessable URL.

Email notifications sent from private repositories will no longer display images; each image is replaced by a link to view it on the web.
Content inside a Git repository is not affected by this change and has always required authentication for private repositories.

Learn more about attaching files.

[aokabi]

Do you have plans to introduce the feature to internal repository in the future?

[vtbassmatt]

Good catch, this also applies to internal repositories :)

[kamilhism]

Hi!

Sorry, is there any plans to return signed links via API? There're a lot of scripts/actions that expect accessible URLs of images and other attachments, and currently all of them are broken since not signed links are being returned via API and event payloads in Actions 😢 As I see right now the only way to get signed link via API is to use graphql API and bodyHTML field, but it's not very convenient... Maybe it makes sense to give ability to pass some header/param (e.g. sign_attachments=true) in request if you don't want to return signed links by default?

Thanks.

[edwarddamato]

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.

[james-skinner-deltatre]

essentially the same issue in our org - deltatre-vxp

[mivano]

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.

[james-skinner-deltatre]

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

[mivano]

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

[grzegorzkrukowski]

Is there a way to disable it for certain repositories?
We are using GitHub Releases to generate our changelog, and we want those images to be exposed to the public. Once this was enabled, it completely broke our release flow.
Such changes should be opt-in or at least opt-out.

[grzegorzkrukowski]

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.

[vtbassmatt]

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.

[grzegorzkrukowski]

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.

[kirsan31]

@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 :(

[wktk]

Looks like the links in notifications from the official Slack integration are broken. I'm not a Teams user, but I'm guessing the official Teams integration might have the same issue. It'd be nice if they could work as well as they do in email notifications! Plus, it used to be that images in the messages were displayed as previews, which was pretty handy. I'd be happy if we could keep that feature.

[vtbassmatt]

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

[urig-40seas]

Hey,

First, we would like to express our gratitude for the effort you have put in to introducing new features and improving the security of Github 🙌🏻 You are awesome guys.

We have a github action that upon merging PR, we extracted the PR's description (including text and images), parsing it, and posting it to an internal Slack channel.

Due to the introduction of secure private attachments, our current logic has been disrupted 😭.

Could you suggest a best practice or provide guidance on how we can create a preview of a PR description for external system?
We prefer not to add the links manually as suggested here - https://github.com/orgs/community/discussions/54551#discussioncomment-5861215, a way for disabling the feature / retrieve somehow the images would be great.

Thank you.

Edit - we did try to add the links manually but they were changed to https://camo.githubusercontent.com/..., really not sure how to tackle this.

[vtbassmatt]

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.

[urig-40seas]

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 ?

[urig-40seas]

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

[vtbassmatt]

Yes, a PAT will work here too. Thanks!

[urig-40seas]

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 '';
};

[orthopteroid]

Hi. I'm a browser user and am logged in to my account. For several years I have been collaborating with another user that has a private repository. We often drag-drop images into issues on that user's private repository. Those images have handily showed up as thumbnails when I view an issue, and they still do. However, when I click on the image to display it full resolution I'm taken to a private-user-images.githubusercontent.com domain and receive a 404. This (thumbnails visible but full resolution not available) occurs for images I've dropped into issues as well as images the repo owner drops into issues.

Obviously something is amiss if I'm able to drop images and see a thumbnail but not the full resolution image (unfortunately the full resolution image is sometimes required). I do have full privs on the repo.

Is there a new setting my collaborator needs to change to ensure I can view the full resolution images?

Followup:

However, I do notice that if I edit an issue and extract the image url from there it links to the full rez image which I can dereference. So, I suppose I have a workaround for now.

[vtbassmatt]

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

[daviewales]

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?

[urig-40seas]

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

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

[urig-40seas]

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.

[ialexryan]

This change is honestly a bummer – it was a really convenient perk of using Github to be able to share PR media with non-engineer coworkers who don't have a Github account by just sharing a link. And it's honestly hard to imagine a realistic threat model where link privacy/security-through-obscurity was insufficient for this kind of content. Yes, technically a change like this makes the Secure-ness thermometer on the wall go up by a point, but at what cost (and opportunity cost)?

[iam-py-test]

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

[ialexryan]

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

[JMBurley]

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.

[expikr]

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?

[samatcodeapprove]

@tuves this is a disappointing breaking change for tools which display GitHub markdown content. Is there a way to generate a "signed" version of one of these new asset URLs without parsing the markdown and making an API request for each one like this comment suggests?

[vtbassmatt]

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.

[mivano]

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

[mivano]

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.

[mkyed]

Thanks @tuves, this is clearly an improvement security-wise. Are you planning a way to audit the already uploaded images as discussed here? We really need a way to remove unintended upload of images containing sensitive information from your servers.

[mkyed]

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

[vtbassmatt]

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

[mkyed]

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.

regret.mov

[vtbassmatt]

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?

[mkyed]

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

[foiseworth]

Hi 👋

We're encountering an issue where images are intermittently (~75% of the time) not showing in our wiki when they have the subdomain private-user-images.githubusercontent.com.

The issue appears to be that the JWT has expired (sometimes by a few minutes and sometimes by 1 hour +).

I initially presumed this was a local browser caching issue however I have turned the browser cache off and the issue remains.

This happens on initial page load so is different from the issue reported by orthopteroid earlier.

Browsers tried are: Arc, Chrome, Chrome Mobile.

[mkyed]

How is this related to the subject of this thread?

[foiseworth]

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

[james-skinner-deltatre]

Is there a way to get image content from a script if your organisation has SSO enabled?

We are facing the same issues as everyone else when trying to publish markdown from a repo. Tried the strategy in this comment but getting back a 200 response to an SSO login page rather than a redirect

[mkyed]

How is this related to the subject of this thread?

[james-skinner-deltatre]

How is it not?

[james-skinner-deltatre]

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

[james-skinner-deltatre]

we need a supported "get repo attachment" API

[igor-nesterov-deltatre]

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

[ravwojdyla]

@tuves thanks for the improvements! In the context of assets uploaded in a private repository, with a paid organization, is there any retention period on the assets? In which circumstances the assets may be deleted by GitHub? What are the storage limits (not individual assets, but total)? What happens when the repository is moved or deleted (assuming the asset was uploaded in one of the comments)? What if the user that uploaded the asset is removed from the organization, does that affect anything? Thank you in advance!

[vtbassmatt]

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

[rmacklin]

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

[vtbassmatt]

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.

[sfc-gh-hpathak]

@tuves Where exactly is this applicable? I think I am still seeing the old behavior

1. Open a PR with a media file in the PR description.
2. The media links to https://private-user-images.githubusercontent.com/ which i can still view without logging in.

What am i missing?

[dwasyl]

@tuves Having run into this change when using the Wiki functionality, it's certainly helpful, but when trying to use a local clone of the wiki, these new secure links also don't let us view the clone wiki repo with the images involved. Everything loads without the images or any way to get them all. While the security aspects are great, for something discrete and in a specific repo (like the Wikis), is there a chance to migrate to those images/attachments being stored in that repo vs externally in a way that's quite difficult to access?

[ocornut]

Email notifications sent from private repositories will no longer display images; each image is replaced by a link to view it on the web. Content inside a Git repository is not affected by this change and has always required authentication for private repositories.

I am not sure this is the right topic, but since about mid-november, all emails notifications for my PUBLIC repository (https://github.com/ocornut/imgui) and its issue tracker have had their image removed and replaced by "(view on web)" links, making e-mails notifications practically useless now.

I am struggling to find any reference about this issue elsewhere.

[rpelissondaitan]

+1
Actually this is happening with new Private repos.
This could be an huge security breach, depends on the uploaded Image.
If the repository is Private, everything related to this should be private too

[expikr]

GitHub comments abused to push malware via Microsoft repo URLs

[MasterInQuestion]

    Sort of clickbait title...

    Does "whatever.com/microsoft" etc. properly indicate Microsoft..?

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[MasterInQuestion]

    This tends to cause cache taint and explosion:
    Due to the ever-changing "jwt" in final URL.

    As in:
    https://github.com/microsoft/vscode/issues/210370#issuecomment-2270683212
    https://github.com/user-attachments/assets/79bfac84-3669-4ce5-a867-bf460d418fb7 (~ 41.93 KiB; PNG: RGBA, 1320x382)
    Comparing mine in "attach".
    .
    Worse would be like in:
    https://github.com/mozilla-mobile/firefox-android/pull/5218#issue-2090573376
    https://github.com/mozilla-mobile/firefox-android/assets/38040960/fd50937d-5442-494e-b4aa-0baf75569a57 (~ 33.91 MiB; WebM: VP9 video, 21.403 s, 24 FPS VFR (avg: 22.61, min: 21.277, max: 25), 2560x1600, YUV 4:2:0, ~ 33.86 MiB; Vorbis audio, 21.369 s, 44,100 Hz, ~ 25.2 KiB)

    Which should cause significant burden for both user and server: unnecessary bandwidth waste.


    From security aspects, changing the URL is entirely unnecessary:
    Mere requesting authentication for those non-public should suffice.

    See also: https://github.com/orgs/community/discussions/54551#discussioncomment-5903362

----

[ JMBurley @ CE 2023-11-10 01:07:49 UTC:
https://github.com/orgs/community/discussions/54551#discussioncomment-6063611
    While the obfuscation was considerable given the length of URL:
    It was very easy for users to post highly confidential information as GitHub images, without being aware they were placing that information into 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 anti-pattern 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. ]

    Refer: https://github.com/MasterInQuestion/talk/discussions/8#discussioncomment-7609546

[MasterInQuestion]

    Horrendous in this case:
    https://github.com/libass/libass/issues/816

    Annoying bandwidth waste (of big PNG) on each load...
    And blocking images outright doesn't appear sensible.

[novium2]

Retiring this post as it is over 6 months old. If you have any questions, consider starting a new post.