Bug 422123

Summary: macOS pre-compiled binary release lacks code-signature or published hash
Product: [Applications] kid3 Reporter: vbzfua <vbzfua>
Component: generalAssignee: 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
The binary release of the macOS kid3.app lacks an Apple DeveloperID code-signature or a published hash value/detached signature for authentication and integrity of the binary/dmg.

Using macOS code-signing and/or publishing a hash/detached signature would allow end-users to verify the integrity of the app/dmg.
Comment 1 Urs Fleisch 2020-05-27 16:18:03 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.
Comment 2 vbzfua 2020-05-27 19:17:03 UTC
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
Comment 3 Urs Fleisch 2020-05-28 05:11:52 UTC
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.
Comment 4 vbzfua 2020-05-28 21:27:35 UTC
(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.
Comment 5 Urs Fleisch 2021-12-29 13:11:43 UTC
*** Bug 447441 has been marked as a duplicate of this bug. ***
Comment 6 Urs Fleisch 2024-08-10 17:47:15 UTC
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?