Summary: | macOS pre-compiled binary release lacks code-signature or published hash | ||
---|---|---|---|
Product: | [Applications] kid3 | Reporter: | vbzfua <vbzfua> |
Component: | general | Assignee: | Urs Fleisch <ufleisch> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | J.F.Lanting |
Priority: | NOR | ||
Version: | 3.8.x | ||
Target Milestone: | --- | ||
Platform: | macOS (DMG) | ||
OS: | macOS | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
vbzfua
2020-05-27 03:16:04 UTC
I know about the code signing process of Apple, but there are two reasons why I am not doing it: - Enrolling as an Apple developper costs 99 USD per year. Kid3 is free software and I do not earn money with it, so why should I give Apple 99 USD every year? - Signing needs Apple hardware. I build all Kid3 binaries (Linux, Windows, macOS, Android) on Linux using cross compilers, but to sign the final image, I would have to pass it to a machine running macOS. So I would have to buy some hardware from Apple (from time to time because after ten years I would not get any security updates). As you can see, the whole process is business for Apple. I could provide a GPG signature of the dmg file (in the same way as for the source code), but this is not convenient for the typical Mac user. Maybe KDE's binary factory could sign DMGs, I will have to check if this would be possible. Yes, the Apple DeveloperID/certificate situation is a real problem for FOSS projects. Many macOS projects do use GPG signatures as there is well maintained and fairly mature GPG software available [1]. Some of the FOSS projects providing GPG signatures for their macOS binary archives are: Handbrake, Thunderbird, Firefox, VeraCrypt, VLC, osxfuse, LibreOffice. Would another option be to simply publish the sha256 of the binary archives separately from the downloads, perhaps at kid3.kde.org ? [1] https://gpgtools.org I have now put SHA256 sums and GPG signatures for all release files into the downloads folder https://sourceforge.net/projects/kid3/files/kid3/3.8.3/ and added links to them on the Kid3 web site https://kid3.kde.org/. As the sha256sum file is signed too, it should be OK not to have it on a separate place. (In reply to Urs Fleisch from comment #3) That looks like a reasonable way to ensure the integrity of the binary releases. Thanks for addressing the issue so quickly. Marking status as: Resolved/Fixed. *** Bug 447441 has been marked as a duplicate of this bug. *** I finally managed to build signed an notarized packages for both the arm64 and x86_64 via the KDE CI/CD infrastructure. Could you please check if kid3-git20240810-Darwin-arm64.dmg and kid3-git20240810-Darwin-amd64.dmg from https://sourceforge.net/projects/kid3/files/kid3/development/ are working correctly? |