> Hello [@eht16](https://github.com/eht16) I have reached the point of creating > the installers
Hooray! Nice to hear. > but I am in the need of key/certificate in order to sign (`codesign_key.pem`, > `codesign.pem`). Should I get a unique set myself? I haven't done this > before, can you point me to where you did get yours? The certificate I used was from https://www.cacert.org. I registered there in 2006 or so and had to meet to couple of people to verify me and so to be able to get a certificate issued. I don't know if the process is still that complicated. In the end it's probably not worth at all. The root certificate of cacert.org is not included in the common OS and browser bundles and so a proper verification can be made only after installing the root certificate of cacert.org manually by the user. I doubt anyone really did this in the past. I only knew a single user who wished those digital signatures and I actually asked here six months ago if this is still the case but she didn't answer. Furthermore, even if you had a certificate, if we will eventually create release installers in the pipeline, you had to upload the private key of the certificate to Github or somewhere else where the CI job can access it. This is something I would never do because you never know what Github does with that key. Additionally, signing an automatically created binary on a third party system (Github runner) with a *personalised* certificate doesn't give much security as you personally cannot verify its complete integrity anyway and in the worst case you personally would be responsible for any malicious code, corruption or whatever, just because it is signed with your certificate. So, I suggest we do not sign the binaries any longer. > For now I changed sign_files to skip if the SIGN_CERTIFICATE_KEY is missing. > There was already an instruction to do that but with a bug as `isfile()` was Sorry for the bug and the trouble it might caused :(. > missing. Wouldn't be better to version geany-release.py and > geany-plugins-release.py in the respective git repos rather than hosting in > the wiki? Fine by me. It might fit in the `scripts` directory in Geany and in the `build` directory in G-P. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/4189#issuecomment-2629001461 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/issues/4189/2629001...@github.com>
