The only thing in my security log over at GitHub that I'm not familiar with is a handful of "repo.change_merge_setting...Blocked a merge setting on the ${my_repo} repository" entries. Googling that provides little information. Can anyone explain what that means? Should I be worried?
Heroku Security Notification
111–120 of 123 posts
Re: Heroku Security Notification
#112Earlier quoted context omitted.
For a while now I've been worried about this -- either integrations asking for full read/write access for a service that might seem to need only read. Or maybe worse, integrations asking for access to anything my account has access to, when I only want to grant it to one repo or organization, or only to public repos and not private ones. Whenever I've reached out to inquire/complain about this, I've been told that gi…
I've been looking into this as I'm building similar per resource scoping for conjure.so's API. GitHub has 'OAuth Apps' and 'GitHub Apps' [0]. The former's scopes do not permit such granularity (eg the `repo` scope gives access to all repos of the account [1]). The latter is much more granular, allowing the user to select specific repos to grant permission [2]. The 'GitHub App' owner can see their installations and al…
Do you think that still sounds much more confusing than it needs to be?
I don't totally understand why they offer these two mechanisms of integration -- or why the granularity of access would need to be different between them. Why not let "OAuth apps" be authorized per-repo -- if you are going to have "OAuth apps" existing as a thing still? And they don't seem to be deprecated in favor of newer "github apps", right?
Re: Heroku Security Notification
#113The only thing in my security log over at GitHub that I'm not familiar with is a handful of "repo.change_merge_setting...Blocked a merge setting on the ${my_repo} repository" entries. Googling that provides little information. Can anyone explain what that means? Should I be worried?
That log entry happens when you change the settings on a repo for what kind of merges are allowed for PRs (merge commit, squash, rebase). It’s three checkboxes under “Pull Requests” in the settings for a repo. I can’t speak to any reason a threat actor would have wanted to change those settings though.
Re: Heroku Security Notification
#114The only thing in my security log over at GitHub that I'm not familiar with is a handful of "repo.change_merge_setting...Blocked a merge setting on the ${my_repo} repository" entries. Googling that provides little information. Can anyone explain what that means? Should I be worried?
That log entry happens when you change the settings on a repo for what kind of merges are allowed for PRs (merge commit, squash, rebase). It’s three checkboxes under “Pull Requests” in the settings for a repo. I can’t speak to any reason a threat actor would have wanted to change those settings though.
I see, thanks. I don't ever remember touching these settings before.
Re: Heroku Security Notification
#115I'm not a security expert, but if you're reading this and wondering what to do, a good start could be to just assume your repo was accessed, and so to run a tool like gitleaks against your repo. If it detects anything sensitive, I'd see about revoking/deleting those secrets right away. In general, it's good practice not to check anything sensitive into source code for precisely this reason (if your code is compromise…
It's such a cryptic call to action. When people reading an incident disclosure end up wondering what to do, you're not finished writing. I haven't logged into or even used Heroku in close to a decade. Am I affected? I just toyed around with a hobby project on Heroku those years ago and didn't release anything. Am I affected? If that project didn't connect Heroku with GitHub, am I affected? It's been so long, I don't even know how to use Heroku anymore or even access my repos there. Yet, I got this message in my E-mail so that would imply that maybe I'm affected and need to do... something? Who knows, the E-mail doesn't say what to do either.
Sounds like the best course of action for someone like me would be to just to log in, find any button that says "delete everything" and use it. So confusing.
Re: Heroku Security Notification
#116Earlier quoted context omitted.
It would not at all be "hard to detect", the SHAs of it and all subsequent commits would change, it would appear in the GitHub audit log, etc etc
Honestly should be pretty easy to just compare remote to someone's recent local copy and just spot check any new commits. Definitely a time sink, though
Yeah it's not the hardest thing to check for, the real problem is that you have to check and you have to know what you're seeing.
Someone who misses the memo on this one, isn't so good at git, and/or is on a smaller project could really be bad news.
Re: Heroku Security Notification
#117I'm not a security expert, but if you're reading this and wondering what to do, a good start could be to just assume your repo was accessed, and so to run a tool like gitleaks against your repo. If it detects anything sensitive, I'd see about revoking/deleting those secrets right away. In general, it's good practice not to check anything sensitive into source code for precisely this reason (if your code is compromise…
It's such a cryptic call to action. When people reading an incident disclosure end up wondering what to do, you're not finished writing. I haven't logged into or even used Heroku in close to a decade. Am I affected? I just toyed around with a hobby project on Heroku those years ago and didn't release anything. Am I affected? If that project didn't connect Heroku with GitHub, am I affected? It's been so long, I don't…
> Sounds like the best course of action for someone like me would be to just to log in, find any button that says "delete everything" and use it. So confusing.
Yet that isn’t even close to the best course of action. If your GitHub account was compromised and you had secrets in private repos, deleting everything in your Heroku account isn’t going to do anything to help.
Re: Heroku Security Notification
#118Earlier quoted context omitted.
Thanks for clarifying. It would still be better if I didn't have to give read access to source code, but could still use the issues integration. But I agree it's not as a bad as write access to source code.
Most error monitoring services want this as they map errors to commits.
I know it's more work, but they could also use Github Actions to push recent commits (past 90 days) to themselves, and use them. That way they wouldn't store or have access to all source code.
Re: Heroku Security Notification
#119I might be naive but how does a threat actor get access to encrypted bunch of keys.
an employe gone rogue?
Re: Heroku Security Notification
#120Earlier quoted context omitted.
I've been looking into this as I'm building similar per resource scoping for conjure.so's API. GitHub has 'OAuth Apps' and 'GitHub Apps' [0]. The former's scopes do not permit such granularity (eg the `repo` scope gives access to all repos of the account [1]). The latter is much more granular, allowing the user to select specific repos to grant permission [2]. The 'GitHub App' owner can see their installations and al…
Do you think that still sounds much more confusing than it needs to be? I don't totally understand why they offer these two mechanisms of integration -- or why the granularity of access would need to be different between them. Why not let "OAuth apps" be authorized per-repo -- if you are going to have "OAuth apps" existing as a thing still? And they don't seem to be deprecated in favor of newer "github apps", right?
Yeah agreed its pretty confusing and took me some time to reconcile!
I imagine for legacy support or business reasons they maintain the OAuth API, but I too wish they add granular repo support to the OAuth API and existing tokens were migrated to an all repos scope, while new tokens were encouraged to be per repo scoping.