TL;DR: A misconfigured bucket meant that images generated by Repography were publicly discoverable, even for private repos.

On Friday Dec 2, 2022, I received an email from a sharp-eyed visitor, who found that it was possible to view the file listing of images.repography.com, a storage bucket where we upload images (dashboards and posters) generated by Repography.

It's intended that the images themselves are publicly accessible, so that they can be directly embedded, but it should only be possible to view an image if the URL is shared by someone who legitimately has access. Obviously the ability to list the contents of the bucket was defeating this aim.

First of all I'd like to offer my sincere apologies to anyone affected by this. It's certainly my fault - I'm the sole developer of Repography, and it's an embarassing mistake. I'm posting this because I think it's important that affected users are made aware of the issue, and also I want to show my sincerity in building a service that you can trust.

Impact

If you used the Repography app before this was fixed on Dec 2, 2022, then the images we generated for your repository were publicly discoverable and accessible.

These images are based on the metadata and history of your repository, so may include information like:

• The names and GitHub avatar image URLs of contributors
• File paths within the repository
• Historical stats based on the commit history and issue activity

I haven't deleted existing files because I don't want to break images which users have already embedded elsewhere, but if you want to move your Repography images to a new unguessable URL you can remove your repo and add it again within the Repography app.

Please note that images might be accessible for a while after being deleted due to caching.

Root cause and resolution

images.repography.com is a Google Cloud Storage bucket. Upon receiving the email I immediately checked the bucket and found that I'd given "allUsers" the permission "Storage Object Viewer".

Google Cloud Storage has roles which distinguish between bucket access and object access, so it's surprising to me at least that "Storage Object Viewer" includes: "Can also list the objects in a bucket."

To restrict "allUsers" to only read objects given the correct path, we actually want the "Storage Legacy Object Reader" role which grants only the "storage.objects.get" permission.

I made this change as quickly as possible (three minutes after receiving the email) and then purged the cache on our CDN.

Awareness and support

If you used Repography with a private repo before the fix on Dec 2, 2022 you should see a notification within the Repography app with a link pointing you towards this blog post for more information. I've identified 87 such users including myself.

If you used the CLI script to analyse a local repository without using the GitHub app then you would also have been briefly affected by this, but these images are automatically deleted after 24 hours. I don't store any information for these repos so don't have a means of contacting these users.

If you are concerned by this issue, whether you received the notification or not, and would like more information or assistance, please get in touch at [email protected].

Next steps

The security and trust of our users are extremely important to me. In the past week I've reviewed the whole codebase from a security perspective and will continue to do so, hardening our services wherever possible.

This has also been an eye-opener. I'm an experienced developer and I'm surprised (and naturally, disappointed) that I made the error which lead to this issue. To minimise the chance of errors like this and to improve the security of Repography overall I'm making two commitments to be done before I remove the "beta" label (hopefully Q1 2023):

• I will commission an independent security audit and post an update on this blog.
• I will make the source code for Repography itself public, so that everyone can review the code for themselves.

If you'd like to support Repography and help me make time to improve it, please consider purchasing one of our paid plans on the GitHub marketplace.

Incident timeline

• 2022-12-02 13:55 UTC: Report received via email to [email protected]
• 2022-12-02 13:58 UTC: Permissions modified, CDN purged (issue fixed)
• 2022-12-02 14:02 UTC: Response to email
• 2022-12-02 - 2012-02-07: Internal review, implementation of notifications, testing
• 2022-12-08: Deployment, further testing
• 2022-12-09: Blog post published, notifications sent

Credit

Many thanks to Wouter Bolsterlee who found this issue and alerted me to it.