search

OWASP / threat-dragon

An open source threat modeling tool from OWASP
https://owasp.org/www-project-threat-dragon/
Apache License 2.0
926 stars 248 forks source link

Automate Release Process #112

Closed lreading closed 3 years ago

lreading commented 3 years ago

Describe what problem your feature request solves The release process currently requires a high level of effort by a maintainer. Despite @jgadsden 's superhero-like ability to pull this off, I think we should make it a bit easier. It may not be practical to get it 100% automated (looking at you, desktop), but if we can get closer that would certainly be a win!

Describe the solution you'd like There's a lot of ways of doing this, but I'm leaning towards having actions that run only on new tags. I don't know yet if there's an action for tags, but maybe milestones or something similar would work?

Additional context

Blockers

There's probably more blockers or things we need to do before we get to the point where we can have an almost full continuous delivery pipeline, but this should suffice to start the conversation.

@jgadsden - Where the release is still very fresh for you, would you care to add what the biggest pain points for you have been this time around so we can focus our efforts on those?

jgadsden commented 3 years ago

Absolutely agree with @lreading on this.

One of the direct things would be the suggestion already made by Leo on automating the docker image push to docker hub #96 . At present it is pushed to threatdragon repo, rather than owasp repo, on docker hub; this was only because we do not yet have the permissions to push to owasp docker hub repo. I will be asking for these permissions and maybe soon we can push to owasp rather than threatdragon

lreading commented 3 years ago

A CI pipeline has been (mostly) implemented on the vue-migration branch. https://github.com/OWASP/threat-dragon/actions/runs/834390970

The pipeline runs front-end and back-end unit tests, creates a docker image, and then uses that image to run e2e tests and a zap scan. As it would turn out, we can use a github action to just run the freshly built container as opposed to an actual deployment on a staging/qa site. The only piece that's left is adding a step to promote it if it is on master, and we can keep the latest tag up to date. It's currently pushing to a personal dockerhub for testing, that is easy enough to change before all of this gets merged.

Is there anything else you'd like to see as far as far as the CI pipeline goes?

lreading commented 3 years ago

In the 2.0 branch, I do have an action that publishes the docker image. It's currently pushing to one of my accounts as a temporary measure. If we're going to be using threatdragon for the interim, would it be possible to add me to that, or to just add a repository secret so we can use it in a GH action to publish the docker image automatically?

I think automating the desktop builds will be the biggest hurdle. Fortunately, GitHub does provide macOS runners as well, so I think it should be do-able.

Do we want to build all the things on every commit to the main branch, or should we just aim for tags to start with? The idea being that if we push a tag, in theory we could auto-generate the release.

jgadsden commented 3 years ago

Cool, tags are fine with me

Let me see what I can do to get you on the threatdragon Docker Hub acccount

I agree that the MacOS installer is the problem one, it has to be built on an Apple machine, and Apple notarization is a proving a big pain Other than that the other electron builder targets (AppImage, snap, NSIS etc) can be built in a Linux container ... hmm, pondering

lreading commented 3 years ago

It appears as though this action does just about everything we need: https://github.com/samuelmeuli/action-electron-builder

~I'm working through a couple of bugs with it at the moment, including one where a failed build will cause the electron process to become stuck, preventing other electron builds from passing on the same runner.~ We need to configure snapcraft appropriately as part of this if we want the github releases automated. It will fail the build without a valid token.

Follow-on items:

The other thing is that we won't get the nice release notes in an automated fashion. That said, we can probably script out at least the shasum generation and update the draft from the action. I'd imagine we will still want to manually add the release notes though. Thoughts?

jgadsden commented 3 years ago

Looks excellent from my point of view I am not too fussed about the release notes, we can always create a changelog.md and put them in there - similar to how json-rules-engine does it

lreading commented 3 years ago

If I'm recalling correctly, the MacOS electron app is being signed by a cert that you own, @jgadsden ?

I've changed course again (in typical fashion) and have had better luck just scripting the builds in actions. There's some weirdness in how electron-builder works under the hood that made me shy away from it.

That said, code-signing and notarizing sounds easy enough... on paper.

From my very limited research, it would seem we need a code signing certificate to sign the windows app. Those can get a bit pricey. I see one from comodo for about $70/year? I'm wondering if this is the type of thing we should be reaching out to OWASP for.

In the branch I'm working in, we are currently on version 1.5.2, and we have a snap published as 1.5.2 on snapcraft. This is actually version 1.5.0, but I needed to bump the versions during testing. For those reasons, could we pull an angular and just make the next official release 1.5.3?

For reference, the draft github release is here: https://github.com/OWASP/threat-dragon/releases/tag/untagged-51f8301345897e14e8d2

Moving forward, this would only be built when a tag (starting with "v") is pushed

jgadsden commented 3 years ago

Yes, the MacOS image is (at present) owned by me ... it was what electron builder picked out of my keystore without me being too aware of what electron-builder was doing. This is part of my yearly Apple Developer licence.

I am happy to buy the Windows code signing certificate - certainly OWASP will pay for this once we are out of incubator stage. And I think it is my turn to pay for something? (until OWASP take these on)

next official release can easily be 1.5.3 , no problem at all @lreading

lreading commented 3 years ago

haha, the apple developer program is more expensive, is it not? ;)

As long as you are fine with using your license for this, I think we can probably get at least MacOS signing/notarization configured, barring any major difficulties (which tend to happen with these things).

I'm going to investigate code signing certs a bit more and will work with you offline to ensure redundant ownership.

Documentation on the GH Action is here: https://github.com/samuelmeuli/action-electron-builder The maintainer has added some nice documentation on how to get the keys and certs required for signing and notarization. I just don't know for sure if notarization will happen "out of the box", or if there will be changes we need to make to the app. I've read a few things about some kind of electron hardened plugin.

We will need the following secrets added to the repository:

jgadsden commented 3 years ago

Took a while (the day job went heavy duty for a while :-) ) but I have put these into the secret store:

If they work OK, and I guess they should, then I will move on to getting:

lreading commented 3 years ago

Thanks for that! The signing appears to be working, however, the notarization is not happening. I'm still trying to work thorough how to get that to happen between electron-builder configurations and the github action.

jgadsden commented 3 years ago

Notarization may be due to the keys - I have not been able to test them, to be treated with scepticism ;-)

The certs are the same ones used for signing the image for 1.4.0 and 1.5.0

lreading commented 3 years ago

It was operator error, definitely not the keys. :) It's my first dive into electron and electron-builder, so it took me a few attempts before I figured out how to configure it properly. It does seem to be notarizing the image, and a very quick test on Big Sur shows that it has been notarized. There is still a warning that the application has been downloaded from the internet, with the caveat that Apple has scanned it for malicious software/files and did not find anything malicious.

The only question is if we want to get these changes in ASAP, or if we want to get the code-signing for Windows sorted before merging?

jgadsden commented 3 years ago

Superb work @lreading - there is no great hurry to release 1.5.1, I was just feeling bad that I had broken the threat engine in 1.5.0

I will get the windows certs today, and then over to you to weave your magic

lreading commented 3 years ago

I'm adding the logic to build and push the docker image as well for the release action. Since I haven't bothered you enough for this yet, would you mind adding the dockerhub username and token to the repo secrets? There are existing ones that can be overridden that I was using for testing actions on the v2-development branch. Those point my own dockerhub account, not really associated with threat dragon.

I believe the only other piece we'd be missing would be adding a zip of the directory to the release, which I will be looking into tonight or tomorrow.

jgadsden commented 3 years ago

Done - updated the existing DOCKERHUB_USERNAME and DOCKERHUB_TOKEN

lreading commented 3 years ago

I believe the only other piece we'd be missing would be adding a zip of the directory to the release, which I will be looking into tonight or tomorrow.

I'm now realizing this happens automatically upon tagging. Once verification is complete for the code-signing cert that Jon was kind enough to get for the Threat Dragon community, this should about ready for merge (assuming the windows build works as well as the macos one did).

After this is merged, a new release can be generated by updating the version in the package.json files (there are multiple), tagging and pushing the changes/tags.

jgadsden commented 3 years ago

This is really really good to see, many thanks @lreading

The windows certs are taking longer than usual because I am known as Jon but that is not my given name so the documents had to be sent up the chain for approval

lreading commented 3 years ago

The automation mostly worked, but it did some weird things with versions. It seems the release it created was one version behind the tag I had created. This will require a bit more investigation, however, the building and signing of binaries is a huge win. We will need a new release when the code-signing cert for Windows is ready, so that'll be another good opportunity to test. :)

jgadsden commented 3 years ago

I have the signing certificate back from Certum / Asseco, and have added the secrets:

I am not that sure if the password is indeed a password or if it is needed

lreading commented 3 years ago

Since the Windows code-signing is in place, I think it's safe to close this as complete. We still don't have access to the official dockerhub group for OWASP, but we do have own own little area that our users expect us to publish to for now. :)

I can't praise Jon enough for his efforts to get the Windows signing in place. That was a tough nut to crack, but he stuck with it and it is included in the 1.5.8 release!