winget support would be great

[exoosh]

Describe what problem your feature request solves:

It would make the installation and upgrading the software on modern Windows very very easy.

Describe the solution you'd like:

I'd love to be able to say winget install --id OWASP.ThreatDragon or similar -- and of course subsequently winget upgrade --id OWASP.ThreatDragon -- in order to install and upgrade the software.

PS: I think there is a way to integrate this with GitHub automation, but I need to dig that up again and will comment once I find it. That way if the assets in your releases follow a particular schema a PR will automatically go to microsoft/winget-pkgs.

[exoosh]

Here's the automation option I had in mind: https://github.com/vedantmgoyal2009/winget-pkgs-automation (apparently now being replaced by https://github.com/marketplace/actions/winget-releaser, example, source)

I'll see if I can figure this out on my own time and will probably send a PR to you, if successful.

[jgadsden]

many thanks @exoosh , if you find out how to do it that would be great. I have assigned it to you, but decline if you want to

[assarbad]

So apparently winget-releaser is the way to go. And with Vim I have found a repo where this is done. So it can probably made to work for this one, too. See here.

Two things, @jgadsden:

1. could you assign it to me (same guy as @exoosh) but my private account?
2. how long do I have until version 2.2?

[jgadsden]

Thanks @assarbad / @exoosh for taking this on. I have given you more permissions for this repo so you should be able to add labels and run tests, that sort of thing
Version 2.1.4 is out this week - version 2.2 sometime second quarter of this year

[exoosh]

I will test this first in a repo of my own just to make sure I get it right. Then will "port" it over here with a PR. In all likelihood there will be some secrets involved that need to be created for the PRs to be posted to winget-pkgs.

[jgadsden]

moveing this back to version 2.4 from version 2.3 - unless this is done @exoosh ? No problem either way

[exoosh]

Apologies. No it's not yet done. But I have indeed now dabbled with winget-releaser. I now know the steps it takes and have actually tried it for a FLOSS project which I maintain. I have only tested it with a proper user, though. Testing it with an org will be the next thing, but it looks like this will work the same.

Windows only has the .exe asset, right? And only a single architecture, @jgadsden?

---

For the record the steps are probably going to be as follows:

1. Head to https://github.com/settings/tokens and generate a (classic!) personal access token with a descriptive label
2. In https://github.com/OWASP/threat-dragon/settings/secrets/actions create a secret with the name WINGET_TOKEN (this follows the convention from winget-releaser)
3. Add the action to this repo (I'll draft one)
4. Create a release (this is what triggers the action)

Alas, there's a catch here. There is currently no OWASP/ThreatDragon manifest. But there needs to be one for komac (which is used by winget-releaser) to build on. So the very very first such release will have to be manual.

Therefore I suggest you ping me here and I'll do the creation of that first manifest so that the automated action can run next time around. How does that sound?

[jgadsden]

that sounds very good to me, thanks @exoosh , and agreed, just one asset and one architecture
I know next to nothing about Windows, so appreciate you taking this on
we can coordinate and when the release is created we can add the winget files / support

[exoosh]

Cool, alright. So to summarize: for the upcoming release I will create the manifest more or less manually and for subsequent ones the GitHub action should take over.

[assarbad]

@jgadsden I'm silly, sorry. We can do the WinGet manifest right now (and get automation in place for the upcoming version before it gets released), I'd just like to get your feedback on my choices for the data to be entered.

Please pay particular attention to the following fields below:

• Publisher:
• PublisherUrl:
• PublisherSupportUrl:
• Author:
• LicenseUrl:
• Copyright:
• CopyrightUrl:
• ShortDescription:
• Description:
• ReleaseNotesUrl:

Also note that some items are populated based on your project settings. E.g. the tags.

Created with Komac 2.6.0:

$ komac new OWASP.ThreatDragon --package-locale en-US --copyright 'Copyright © 2015 - 2024 OWASP' --publisher 'OWASP' --publisher-url https://owasp.org/ --publisher-support-url https://github.com/OWASP/threat-dragon/issues/new/choose --package-name ThreatDragon --package-url https://github.com/OWASP/threat-dragon/releases --author 'OWASP contributors' --moniker threatdragon --license Apache-2.0 --license-url https://github.com/OWASP/threat-dragon/blob/main/license.txt --short-description 'Threat Dagon is an open source threat modeling tool and is an official OWASP project. It is used to draw threat modeling diagrams and to list threats for elements in the diagram' --description "OWASP Threat Dragon is a free, open-source, cross-platform threat modeling application. It is used to draw threat modeling diagrams and to list threats for elements in the diagram along with their remediations.\nThreat Dragon is designed to be accessible for various types of teams, with an emphasis on flexibility and simplicity. It is an OWASP Lab Project and follows the values and principles of the threat modeling manifesto" --release-notes-url https://github.com/OWASP/threat-dragon/releases/tag/v2.2.0 -v 2.2.0 -u https://github.com/OWASP/threat-dragon/releases/download/v2.2.0/Threat-Dragon-ng-Setup-2.2.0.exe

Draft version of manifest files

In case I somehow don't respond, the following files ought to go under the name given in their subsection titles respectively into https://github.com/microsoft/winget-pkgs/tree/master/manifests/o/OWASP into a subdirectory ThreatDragon.

OWASP.ThreatDragon.installer.yaml

# Created with komac v2.6.0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.6.0.schema.json

PackageIdentifier: OWASP.ThreatDragon
PackageVersion: 2.2.0
InstallerType: nullsoft
InstallModes:
- interactive
- silent
UpgradeBehavior: install
ReleaseDate: 2024-02-17
Installers:
- Architecture: x86
  InstallerUrl: https://github.com/OWASP/threat-dragon/releases/download/v2.2.0/Threat-Dragon-ng-Setup-2.2.0.exe
  InstallerSha256: D5295584C6EDBBFA8515218C173E9125ADD690D5DEDE37702FC0B7D7FDD5E93A
ManifestType: installer
ManifestVersion: 1.6.0

OWASP.ThreatDragon.locale.en-US.yaml

NB: The Description field was added after the Komac invocation.

# Created with komac v2.6.0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.defaultLocale.1.6.0.schema.json

PackageIdentifier: OWASP.ThreatDragon
PackageVersion: 2.2.0
PackageLocale: en-US
Publisher: OWASP
PublisherUrl: https://owasp.org/
PublisherSupportUrl: https://github.com/OWASP/threat-dragon/issues/new/choose
Author: OWASP contributors
PackageName: Threat-Dragon-ng
PackageUrl: https://github.com/OWASP/threat-dragon/releases
License: Apache-2.0
LicenseUrl: https://github.com/OWASP/threat-dragon/blob/main/license.txt
Copyright: Copyright © 2015 - 2024 OWASP
CopyrightUrl: https://github.com/OWASP/threat-dragon
ShortDescription: Threat Dagon is an open source threat modeling tool and is an official OWASP project. It is used to draw threat modeling diagrams and to list threats for elements in the diagram
Description: |
    OWASP Threat Dragon is a free, open-source, cross-platform threat modeling application. It is used to draw threat modeling diagrams and to list threats for elements in the diagram along with their remediations.
    Threat Dragon is designed to be accessible for various types of teams, with an emphasis on flexibility and simplicity. It is an OWASP Lab Project and follows the values and principles of the threat modeling manifesto
Moniker: threatdragon
Tags:
- owasp
- owasp-threat-dragon
- sdlc
- threat-dragon
- threat-modeling
ReleaseNotesUrl: https://github.com/OWASP/threat-dragon/releases/tag/v2.2.0
ManifestType: defaultLocale
ManifestVersion: 1.6.0

OWASP.ThreatDragon.yaml

# Created with komac v2.6.0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.version.1.6.0.schema.json

PackageIdentifier: OWASP.ThreatDragon
PackageVersion: 2.2.0
DefaultLocale: en-US
ManifestType: version
ManifestVersion: 1.6.0

Draft for winget-releaser action

Probably best to give it a name similar to .github/workflows/publish-release-to-winget-pkgs.yml:

name: Publish releases to winget-pkgs
on:
  release:
    types: [released]
jobs:
  publish:
    runs-on: windows-latest
    steps:
      - name: Get version
        id: get-version
        run: |
          # Finding the version from release name
          $VERSION="${{ github.event.release.name }}" -replace '^v '
          "version=$VERSION" >> $env:GITHUB_OUTPUT
        shell: pwsh
      - uses: vedantmgoyal9/winget-releaser@main
        with:
          identifier: OWASP.ThreatDragon
          version: ${{ steps.get-version.outputs.version }}
          installers-regex: '\.exe$'
          token: ${{ secrets.WINGET_TOKEN }}

The types: [released] ensures this will only trigger for releases.

We could also get this done with with ubuntu-latest and Bash for the runner and script part, it would require adjusting the script accordingly, e.g.:

        run: |
          # Finding the version from release name
          $VERSION="${{ github.event.release.name }}"
          "version=${VERSION#v}" >> $env:GITHUB_OUTPUT
        shell: bash

But winget-releaser uses Powershell anyway, so it probably doesn't make much of a difference. I suspect the Ubuntu runner does have Powershell available as well.

The WINGET_TOKEN needs to be created and registered in the repo which does the release. For good measure we need to clone winget-pkgs on the same user or set via fork-user it as per the README for winget-releaser. That winget-pkgs fork is going to be the source of the PR filed at microsoft/winget-pkgs and the PRs are being opened on behalf of the owner of the used token.

1. Head to https://github.com/settings/tokens and create a new (classic) personal access token with only the public_repo scope activated for it
2. In https://github.com/OWASP/threat-dragon/settings/secrets/actions create a secret named WINGET_TOKEN (as per vedantmgoyal9/winget-releaser)
3. Commit the above action as .github/workflows/publish-to-winget-pkgs.yml
4. Create a (subsequent) release

PS: some more contextual information regarding winget-releaser can be found at windirstat/windirstat#88

[jgadsden]

Hello @assarbad , thanks for all this - certainly it looks practical

Some suggestions but I am not 100% sure:

• Publisher: 'OWASP' rather than 'OWASP Threat Dragon'
• PublisherUrl: 'https://owasp.org/' instead of 'https://github.com/OWASP/threat-dragon/'
• Copyright: 'Copyright © 2015 - 2024 OWASP' instead of 'Copyright © 2024 OWASP Threat Dragon'
• ShortDescription could be changed to "Threat Dagon is an open source threat modeling tool and is an official OWASP project. It is used to draw threat modeling diagrams and to list threats for elements in the diagram"
• Description could be changed to "OWASP Threat Dragon is a free, open-source, cross-platform threat modeling application. It is used to draw threat modeling diagrams and to list threats for elements in the diagram along with their remediations.
  Threat Dragon is designed to be accessible for various types of teams, with an emphasis on flexibility and simplicity. It is an OWASP Lab Project and follows the values and principles of the threat modeling manifesto"

[jgadsden]

I can create tokens sometime this week - are we able to try it out with a test tag? say 2.3.0-RC1 ?

[exoosh]

I can create tokens sometime this week - are we able to try it out with a test tag? say 2.3.0-RC1 ?

Generally yes, but I'd recommend putting that into a separate Github action (i.e. any pre-release channels). At least I wouldn't want to get pre-release versions on a channel I expect release versions on. Let me get back to you in the evening on my own time.

[assarbad]

Cool, I'll do these changes to the files above.

I saw there was an older v2.0.4-RC2 already. If we want to create an RC I can certainly do that and we can make it so that it only triggers when types: [published] fires (not types: [released]). It should simply be a different manifest, e.g. OWASP.ThreatDragon.RC.

I'll have to survey existing RC versions on WinGet to get an idea what our options are.

btw: some of the values are extracted by Komac, in particular some of those values I gave on the command line seem to have been overwritten by something else already. So my guess would be it extracts these from the installer file meta data or so.

[assarbad]

If we were talking about Windows Installer, we could logically separate the RC from the release versions (via UpgradeCode). But with the installer as it stands, this won't be possible. So even if two channels are used, it will probably happen that the detections WinGet uses will end up detecting both. Meaning someone who has installed OWASP.ThreatDragon at version 1.0.0 may end up getting offered RC (OWASP.ThreatDragon.RC) version 1.1.0-RC2 and only once 1.1.0 becomes a release it will offer that as OWASP.ThreatDragon version 1.1.0. This is okay as long as you're in the pre-release phase. But the opposite case is less desirable. So this needs careful consideration.

[jgadsden]

agreed @assarbad , if I can help then say, but otherwise will follow what you think

[jgadsden]

@assarbad did you want to manually create a winget installer for version 2.2.0 ? just to see if everything is in place?
version 2.3.0 is due out by end of this month (October)

[assarbad]

@jgadsden Planning to create the manifest tonight. Created and merge is pending.