The exfiltrated environment variables contained these entries:

``` "POSTGRESQL_DATABASE": "(CENSORED)", "POSTGRESQL_HOST": "(CENSORED)", "POSTGRESQL_PASSWORD": "(CENSORED)", "POSTGRESQL_USER": "(CENSORED)", ```

Sure, but connections from these worker machines shouldn’t be allowed directly to the database.

The security researcher noticed that CodeRabbit runs linters against your code base and noticed that Rubocop was among the provided linters. Rubocop supports extensions that contain custom code, so he crafted an extension that exfiltrated the environment variables of the running Rubocop process when it linted the contents of his PR.

But where does the configuration for Rubocop come from? From CodeRabbit (e.g. you configure it on their server for your repo), from the repository or (new) config files in the PR?

Both the repo and new config in the PR.

Howon, you can stop posting that canned response. It's not helping the discussion in any way and matches the lack of detail the other commenters have pointed out.

Never heard of the product and just had a look at the landing page. Immediately spotted a typo :D

> On Mac, Window and Linux

should be

> On Mac, Windows and Linux

Well that’s embarrassing, thats been there for literal years.

At least the icons are right!

Shouldn’t it be macOS?

Apple would say that, but I think most Mac users would say Mac. I know I think so and I've been a lifelong user.

Space goes after the comma, not in front of it.

Seconded, it’s really irritating

Doesn't this effectively render corporate CAs useless?

Another comment mentioned [0]. Enterprise and people running a private CA can set "security.pki.certificate_transparency.disable_for_hosts" to disable CT for certain domains (plus all their subdomains).

I just hope they automatically disable it for non-public tlds, both from IANA and RFC 6762.

[0] https://wiki.mozilla.org/SecurityEngineering/Certificate_Tra...

> Doesn't this effectively render corporate CAs useless?

All of the browsers ignore transparency for enterprise roots. To determine which is which, the list of actual public roots is stored separately in the CA database, listed in chrome://certificate-manager/crscerts for Chrome and listed as a "Builtin Object Token" in Firefox's Certificate Manager.

No, it just makes any CA accountable for all the certs they issue.

I was confused by the title because when my bubble talks about Vale they mean this:

https://github.com/errata-ai/vale

There is also https://project-everest.github.io/vale/, which is a programming language used in formal verification.

I was slightly confused when I first read the title as well :)

Unfortunately, it leaves a lot to be desired. I've actually had to do a fair bit of GH access reporting myself recently and I can recommend the GraphQL API as it allows you to properly list direct and indirect permissions on repositories (org + team + direct collaborator) that are alot harder to do with the REST API due to its inconsistent permissions model.

IME, the problem with the GraphQL API is that it does a poor job of indicating where permissions came from, and you have to fall back to bad heuristics.

For example, if team="company" has "READ", and team="company/dev" has "WRITE", and Bob is in team="company/dev" but not team="company", then Bob will have both "READ" and "WRITE" because of his membership in team="company/dev"; the API will give no indication that the "READ" indirectly came from team="company".

Also, the permissions that the PAT needs in order for GraphQL to even list those things is excessive.

Anyway, here's my audit script for such things: https://github.com/datawire/collaborators

That's actually incorrect. Check out this query: https://gist.github.com/megamorf/9c105ac9cc13a93b5449a7b683d...

I have added two output examples. One for when you only want to find users that have been directly assigned to a repo (DIRECT) and one that shows how their roles and team memberships decide what permissions they have on a repo.

If they've fixed it in the last 5 months, then hooray.

Having write already implies that you have read, it't not something related to being in a team with read, it's just that write always gives you read. The permission levels are pull(read), triage(read+issues/pr's), push(read+write), maintain, and admin

> Having write already implies that you have read

Yes, but if it's just being implied then it won't list "READ" separately in the "permissionSources", it will just list "WRITE".

i've also been working on a similar tool -- working towards open sourcing it too. would you be interested in taking a look? paul.quenra at conductorone com

I believe you might have a typo in your mail? Just making sure you're not missing out on something useful :)

thank you -- can't edit it anymore, but paul.querna (spelled my own name wrong)

Nice, do you have anything you can share?