Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Release workflow: keep the macOS certificate off the Windows dry-run build

Open Beginner friendly
#2,223 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
electron, github-actions, yaml
Domain
ci-cd, release

Research direction

Read release-local.yml and the Known gap section of docs/architecture/packaging.md. Check how the workflow passes CSC_LINK and CSC_KEY_PASSWORD to macOS and Windows runners, and compare that with the issue's cited Windows dry-run log. Done means credentials are limited to macOS or Windows dry runs are unsigned, the workflow comment matches, and the packaging note is updated.

Written by the indexing model from the issue text.

Description

desktop security

release-local.yml passes CSC_LINK (the macOS .p12) to every runner with no OS guard. On a dry run, where Azure Trusted Signing is not configured, electron-builder therefore signs every Windows .exe through signtool with the macOS certificate: the 2.1.0 dry run (run 37102724459, attempt 2, Windows job 111420891288) logs each signing with certificateFile=...\3.p12. The workflow's own comment says dry runs build unsigned. So a dry run never exercises Windows signing as it ships, and a lapsed Azure client secret shows only on the tag.

Done when: CSC_LINK/CSC_KEY_PASSWORD reach only the macOS runner (or Windows dry runs are deliberately unsigned), the comment matches, and the Known gap in docs/architecture/packaging.md is updated.

Dominant language
Python
Stars
16.3k
Forks
1.6k
Avg merge
9h 15m
Merged PRs (30d)
254

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MODSetter/SurfSense

All issues in MODSetter/SurfSense

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.