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.
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. ***