.github/workflows/mypy.yml

@@ -0,0 +1,23 @@
+name: Mypy
+on: workflow_dispatch
+
+jobs:
+  mypy_py3:
+    name: Mypy check
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+      - name: Setup Python
+        uses: actions/setup-python@v4
+        with:
+          python-version: 3.9
+          cache: 'pip'
+      - name: Checkout
+        uses: actions/checkout@master
+      - name: Install Dependencies
+        run: |
+          pip install mypy
+      - name: mypy
+        run: |
+          make mypy

.github/workflows/publish-release-docker.yml

@@ -0,0 +1,61 @@
+#
+name: Create and publish a Docker image
+
+# Configures this workflow to run every time a release is published.
+on:
+  workflow_dispatch:
+  release:
+    types: [published]
+
+# Defines two custom environment variables for the workflow. These are used for the Container registry domain, and a name for the Docker image that this workflow builds.
+env:
+  REGISTRY: ghcr.io
+  IMAGE_NAME: ${{ github.repository }}
+
+# There is a single job in this workflow. It's configured to run on the latest available version of Ubuntu.
+jobs:
+  build-and-push-image:
+    runs-on: ubuntu-latest
+    # Sets the permissions granted to the `GITHUB_TOKEN` for the actions in this job.
+    permissions:
+      contents: read
+      packages: write
+      attestations: write
+      id-token: write
+      #
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+      # Uses the `docker/login-action` action to log in to the Container registry registry using the account and password that will publish the packages. Once published, the packages are scoped to the account defined here.
+      - name: Log in to the Container registry
+        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
+        with:
+          registry: ${{ env.REGISTRY }}
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+      # This step uses [docker/metadata-action](https://github.com/docker/metadata-action#about) to extract tags and labels that will be applied to the specified image. The `id` "meta" allows the output of this step to be referenced in a subsequent step. The `images` value provides the base name for the tags and labels.
+      - name: Extract metadata (tags, labels) for Docker
+        id: meta
+        uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
+        with:
+          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
+      # This step uses the `docker/build-push-action` action to build the image, based on your repository's `Dockerfile`. If the build succeeds, it pushes the image to GitHub Packages.
+      # It uses the `context` parameter to define the build's context as the set of files located in the specified path. For more information, see "[Usage](https://github.com/docker/build-push-action#usage)" in the README of the `docker/build-push-action` repository.
+      # It uses the `tags` and `labels` parameters to tag and label the image with the output from the "meta" step.
+      - name: Build and push Docker image
+        id: push
+        uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
+        with:
+          context: .
+          push: true
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+
+      # This step generates an artifact attestation for the image, which is an unforgeable statement about where and how it was built. It increases supply chain security for people who consume the image. For more information, see "[AUTOTITLE](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)."
+      - name: Generate artifact attestation
+        uses: actions/attest-build-provenance@v1
+        with:
+          subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME}}
+          subject-digest: ${{ steps.push.outputs.digest }}
+          push-to-registry: true
+

.github/workflows/ruff.yml

@@ -4,16 +4,24 @@ on:
     branches: [ main ]
   pull_request:
     branches: [ main ]
+
 jobs:
   ruff_py3:
     name: Ruff syntax check
     runs-on: ubuntu-latest
+
     steps:
+      - uses: actions/checkout@v4
+      - name: Setup Python
+        uses: actions/setup-python@v4
+        with:
+          python-version: 3.9
+          cache: 'pip'
       - name: Checkout
         uses: actions/checkout@master
       - name: Install Dependencies
         run: |
-          pip install --user ruff
+          pip install ruff
       - name: ruff
         run: |
-          ruff check --output-format github .
+          make ruff

.github/workflows/scripts/update-ios-releases.py

@@ -54,7 +54,7 @@ def parse_latest_ios_versions(rss_feed_text):
 
 
 def update_mvt(mvt_checkout_path, latest_ios_versions):
-    version_path = os.path.join(mvt_checkout_path, "mvt/ios/data/ios_versions.json")
+    version_path = os.path.join(mvt_checkout_path, "src/mvt/ios/data/ios_versions.json")
     with open(version_path, "r") as version_file:
         current_versions = json.load(version_file)
 

.github/workflows/tests.yml

@@ -0,0 +1,38 @@
+name: Tests
+on:
+  push:
+    branches: [ main ]
+  pull_request:
+    branches: [ main ]
+
+jobs:
+  build:
+    name: Run Python Tests
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ['3.8', '3.9', '3.10']  # , '3.11']
+
+    steps:
+      - uses: actions/checkout@v4
+      - name: Set up Python ${{ matrix.python-version }}
+        uses: actions/setup-python@v4
+        with:
+          python-version: ${{ matrix.python-version }}
+      - name: Install Python dependencies
+        run: |
+          make install
+          make test-requirements
+      - name: Test with pytest
+        run: |
+          set -o pipefail
+          make test-ci | tee pytest-coverage.txt
+
+      - name: Pytest coverage comment
+        continue-on-error: true # Workflows running on a fork can't post comments
+        uses: MishaKav/pytest-coverage-comment@main
+        if: github.event_name == 'pull_request'
+        with:
+          pytest-coverage-path: ./pytest-coverage.txt
+          junitxml-path: ./pytest.xml

.github/workflows/update-ios-data.yml

@@ -21,6 +21,7 @@ jobs:
           title: '[auto] Update iOS releases and versions'
           commit-message: Add new iOS versions and build numbers
           branch: auto/add-new-ios-releases
+          draft: true
           body: |
             This is an automated pull request to update the iOS releases and version numbers.
           add-paths: |

.safety-policy.yml

@@ -6,4 +6,6 @@
 security: # configuration for the `safety check` command
     ignore-vulnerabilities: # Here you can list multiple specific vulnerabilities you want to ignore (optionally for a time period)
         67599: # Example vulnerability ID
+            reason: disputed, inapplicable
+        70612:
             reason: disputed, inapplicable

CONTRIBUTING.md

@@ -1,19 +1,65 @@
-# Contributing
+# Contributing to Mobile Verification Toolkit (MVT)
 
-Thank you for your interest in contributing to Mobile Verification Toolkit (MVT)! Your help is very much appreciated.
+We greatly appreciate contributions to MVT!
 
+Your involvement, whether through identifying issues, improving functionality, or enhancing documentation, is very much appreciated. To ensure smooth collaboration and a welcoming environment, we've outlined some key guidelines for contributing below.
 
-## Where to start
+## Getting started
 
-Starting to contribute to a somewhat complex project like MVT might seem intimidating. Unless you have specific ideas of new functionality you would like to submit, some good starting points are searching for `TODO:` and `FIXME:` comments throughout the code. Alternatively you can check if any GitHub issues existed marked with the ["help wanted"](https://github.com/mvt-project/mvt/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) tag.
+Contributing to an open-source project like MVT might seem overwhelming at first, but we're here to support you!
 
+ Whether you're a technologist, a frontline human rights defender, a field researcher, or someone new to consensual spyware forensics, there are many ways to make meaningful contributions.
+
+ Here's how you can get started:
+
+1. **Explore the codebase:**
+    - Browse the repository to get familar with MVT. Many MVT modules are simple in functionality and easy to understand.
+    - Look for `TODO:` or `FIXME:` comments in the code for areas that need attention.
+
+2. **Check Github issues:**
+    - Look for issues tagged with ["help wanted"](https://github.com/mvt-project/mvt/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) or ["good first issue"](https://github.com/mvt-project/mvt/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) to find tasks that are beginner-friendly or where input from the community would be helpful.
+
+3. **Ask for guidance:**
+
+    - If you're unsure where to start, feel free to open a [discussion](https://github.com/mvt-project/mvt/discussions) or comment on an issue.
+
+## How to contribute:
+
+1. **Report issues:**
+
+ - Found a bug? Please check existing issues to see if it's already reported. If not, open a new issue. Mobile operating systems and databases are constantly evolving, an new errors may appear spontaniously in new app versions.
+
+ **Please provide as much information as possible about the prodblem including: any error messages, steps to reproduce the problem, and any logs or screenshots that can help.**
+
+
+2. **Suggest features:**
+    - If you have an idea for new functionality, create a feature request issue and describe your proposal.
+
+3. **Submit code:**
+    - Fork the repository and create a new branch for your changes.
+    - Ensure your changes align with the code style guidelines (see below).
+    - Open a pull request (PR) with a clear description of your changes and link it to any relevant issues.
+
+4. **Documentation contributions:**
+    - Improving documentation is just as valuable as contributing code! If you notice gaps or inaccuracies in the documentation, feel free to submit changes or suggest updates.
 
 ## Code style
+Please follow these code style guidelines for consistency and readability:
+
+- **Indentation**: use 4 spaces per tab.
+- **Quotes**: Use double quotes (`"`) by default. Use single quotes (`'`) for nested strings instead of escaping (`\"`), or when using f-formatting.
+- **Maximum line length**:
+    - Aim for lines no longer than 80 characters.
+    - Exceptions are allowed for long log lines or strings, which may extend up to 100 characters.
+    - Wrap lines that exceed 100 characters.
+
+Follow [PEP 8 guidelines](https://peps.python.org/pep-0008/) for indentation and overall Python code style. All MVT code is automatically linted with [Ruff](https://github.com/astral-sh/ruff) before merging.
+
+Please check your code before opening a pull request by running `make ruff`
 
-When contributing code to 
 
-- **Indentation**: we use 4-spaces tabs.
+## Community and support
 
-- **Quotes**: we use double quotes (`"`) as a default. Single quotes (`'`) can be favored with nested strings instead of escaping (`\"`), or when using f-formatting.
+We aim to create a supportive and collaborative environment for all contributors. If you run into any challenges, feel free to reach out through the discussions or issues section of the repository.
 
-- **Maximum line length**: we strongly encourage to respect a 80 characters long lines and to follow [PEP8 indentation guidelines](https://peps.python.org/pep-0008/#indentation) when having to wrap. However, if breaking at 80 is not possible or is detrimental to the readability of the code, exceptions are tolerated. For example, long log lines, or long strings can be extended to 100 characters long. Please hard wrap anything beyond 100 characters.
+Your contributions, big or small, help improve MVT and are always appreciated.