Signed install

[skv-headless]

based on https://community.developer.atlassian.com/t/action-required-atlassian-connect-installation-lifecycle-security-improvements/49046

• need more testing
• compare with ACE implementation

[skv-headless]

I think that condition is not enough. We also need to check descriptor. Not sure if we can do that

ACE reference https://bitbucket.org/atlassian/atlassian-connect-express/src/4bb8249ec63241ba6b22bdfcf28759362c54dcc9/lib/middleware/verify-installation.js#lines-88

[pawelniewie]

You mean to know if we are using signed installs or not? I think we can add flag to the configuration that would solve that, WDYT?

[skv-headless]

Yeah. I think adding flag is the only option

[stefan-hc]

Looks good to me. You've asked on slack about possible things to break/test, rough list:

• test with two dev Jira instances having app already installed: let one (J1) have installed 'previous' version of app without these changes, second one (J2) already with these changes, then run the backend for both instances:
• both should be able to uninstall -> install with old descriptor -> uninstall
• J2 should be able to disable -> enable (using the same app version) - I don't expect this to be affected, but better check if it still works
• on J1: test that app upgrade (installation of the new version) does work
• test unavailability of 'connect-install-keys.atlassian.com' host (will the app+jira provide meaningful error to the customer? will the app logs contain useful message for the app supporters?)
• anything else? 🤔

[skv-headless]

@stefan-hc

• J2 should be able to disable -> enable (using the same app version) - I don't expect this to be affected, but better check if it still works

didn't understand 😞 what should I disable -> enable?

• test unavailability of 'connect-install-keys.atlassian.com' host (will the app+jira provide meaningful error to the customer? will the app logs contain useful message for the app supporters?)

Added log. The error message looks like this

[stefan-hc]

what should I disable -> enable?

Good question. I believe (but my memory might fail me) that at some point in the past there was more buttons in "Manage your apps" page in Jira: not only "uninstall" "install" "subscribe" etc, but also "disable" "enable". If you check Atlassian documentation there are even some mentions about app disabling/enabling: https://support.atlassian.com/jira-cloud-administration/docs/integrate-apps/

Might be it is copy-paste from Jira Server/DataCenter (where you can disable arbitrary apps, heck, you can disable it's modules one by one), might be that Atlassian has removed Enabling/Disabling function from Jira Cloud...

Perhaps "subscribe / unsubscribe" is current name of "enable / disable". What I suggest:

• play a bit with subscribe / unsubscribe - I believe these might call backend on "/enabled" "/disabled" endpoints (instead of /installed /uninstalled). I suppose nothing has changed from the Atlassian side, but it nonetheless might be good idea to check happy path
• if subscribe/unsubscribe is doing something completely different - ignore my "J2 should be able to disable -> enable" request: it has totally no sense.

Ok for you?

[skv-headless]

what should I disable -> enable?

Good question. I believe (but my memory might fail me) that at some point in the past there was more buttons in "Manage your apps" page in Jira: not only "uninstall" "install" "subscribe" etc, but also "disable" "enable". If you check Atlassian documentation there are even some mentions about app disabling/enabling: https://support.atlassian.com/jira-cloud-administration/docs/integrate-apps/

Might be it is copy-paste from Jira Server/DataCenter (where you can disable arbitrary apps, heck, you can disable it's modules one by one), might be that Atlassian has removed Enabling/Disabling function from Jira Cloud...

Perhaps "subscribe / unsubscribe" is current name of "enable / disable". What I suggest:

• play a bit with subscribe / unsubscribe - I believe these might call backend on "/enabled" "/disabled" endpoints (instead of /installed /uninstalled). I suppose nothing has changed from the Atlassian side, but it nonetheless might be good idea to check happy path
• if subscribe/unsubscribe is doing something completely different - ignore my "J2 should be able to disable -> enable" request: it has totally no sense.

Ok for you?

Tested on staging. Everything works fine for me

[stefan-hc]

Awesome.

[bulinutza]

Happy to see more contributors to this gem!