Why does adopting Forge manifest have to be so hard?

Forge Adopting Forge from Connect
1

As with many others, we are currently in the middle of migrating our suite of Connect apps to Forge, starting by adopting Forge manifest (Connect-on-Forge).

We successfully completed this process for one app, and we’re now onto our second, hoping for a smoother process this time around as we’ve been through it once before. Alas…

To set the scene, we completed the initial migration from atlassian-connect.json → manifest.yml a while back, and successfully tested the successor app in development and staging environments. Today was the final stage of:

  1. Deploying the app to production (forge deploy -–environment production)
  2. Creating a new version of our app in the Marketplace vendor portal (type: Forge app)
  3. Awaiting approval of the new version

It should be noted that this app has been in the Marketplace since 2016 (10 years) and the new Forge version contains no new features, permissions etc. The only change is the adoption of Forge manifest.

As with all Forge apps, the first version starts at 2.0.0; and this was what our Marketplace version was created as. This version went into “Versions pending Marketplace approval” as expected.

Then a second version, 2.1.0 was automatically created by “Marketplace Hub [Atlassian]” (which would historically have been when a change to atlassian-connect.json is detected, but here there was no such change). The same thing happened with our first app. We don’t know why this happens.

So at this point we have two new versions (2.0.0 and 2.1.0) sitting in “Versions pending Marketplace approval”, two ECOHELP tickets, two requests to complete the Forge App Security Questionnaire, etc. So we’ll ignore the 2.0.0 release and focus on the latest one, 2.1.0.

Shortly after, we receive two notifications indicating that both versions (2.0.0 and 2.1.0) failed security scanning (which again happened when we went through this process with our first app, so we were sort of expecting this…..clearly the Connect security scanner and Forge security scanner are not the same, because again, NO changes in this new version). Last time, the issues were false positives to do with atlassian-connect-express itself, so these are likely to be the same issues….and hopefully we can just point to the previous AMS ticket outcome and say “same as this”.

The link provided in the ECOHELP ticket titled “AMS project” is a JQL query that I’m assuming should surface the new AMS ticket to let us know what security issue it supposedly found, but that query yields no results. Similarly, our Atlassian Marketplace Security Dashboard shows no open AMS tickets, and we received not notifications about new AMS tickets.

So at this point the Connect-on-Forge version of our 10 year old, unmodified application is Rejected, and we have no way to see why.

For a process that Atlassian are expecting every vendor with a Connect app to go through, it is very unpolished and hostile.

6 Likes
2

Oh I can relate! We were also forced to undergo the Partner Verification which was hidden somewhere in the first slew of comments the bot had created on the approval ticket and which, of course, went unnoticed. This is compounded by the problem that we are forced to use the user account that “owns” the forge app, which is not the one that usually does the assessments and handles the tickets. The whole process is utterly confusing and I’m dreading the day when we are actually moving to full forge resp right now I feel not like we are going to go forward with that part.

Please do keep us updated on your progress!

1 Like
3

It gets worse.

Today, two AMS tickets were raised in relation to our submission. We were informed by Atlassian that the delay in raising these was due to “an issue on our end that prevented the scanner tickets from surfacing, we are actively working on a resolution”. OK, fine.

Both tickets mention “Vulnerable library versions were found in lockfile(s): package.json, package-lock.json”. The library mentioned is elliptic.

There is no trace of elliptic in our package.json or package-lock.json files. Running the command npm why elliptic returns “No dependencies found matching elliptic”. So we referred these back to Atlassian as potential false positives, and within a few hours they were confirmed as such.

To recap:

  • Our unmodified, 10 year old application gets rejected
  • We waste a whole day waiting to find out why
  • In the end it is a non-issue….an utter false positive for a dependency we don’t even use

With the “security” issues sorted, we resubmit our 2.1.0 version.

Now we have 3rd ECOHELP ticket, and again we’re asked to complete the Forge App Security Questionnaire (which we’ve done twice already), and we’re once again in the queue for approval.

At this point it would not surprise me to see the resubmission rejected with yet another spurious security issue.

Atlassian is a 40 billion dollar company.

6 Likes