Our build and download servers are the same server. If I understand correctly, hacking the server will not only allow an attacker to replace binaries but to sign anything too. Is there any sense in signing for such a setup?

dunkaist wrote: ↑Wed Sep 25, 2024 3:55 pm Our build and download servers are the same server. If I understand correctly, hacking the server will not only allow an attacker to replace binaries but to sign anything too. Is there any sense in signing for such a setup?

Of course there is. If you are a normal user and have already the public key from the Kolibri developers in your key ring, then the signature of a new binary must match this public key. A hacker cannot fake this. A hacker could just sign the binaries with his own public key, but that would be noticed if the user already had the Kolibri public key. In addition, the key distribution is usually done via key servers. Thus the signature and the public key are not on the same servers.

And if you revoke the old key to make a new one the main key, then the new one would be part of the key chain. A hacker's public key would be completely different.

For security reasons, it would make a lot of sense to separate the build server from the download server. Do you also have the version control system with the assembler source code repository on the build server?

We have the only server. If we sign our build artifacts, the private key has to be stored on the same server. Hence, a lucky attacker could sign anything with our key by calling existing server scripts. We are limited in resources to have several servers. First of all, human resources to admin the infrastructure.

In this case you have a security hole. Your binaries can't be trusted.

There could also be an intention behind this, so that you could deny that Kolibri OS is used to distribute malware. Then you would still have an excuse and could say that you are not qualified to set up proper security. The damage to the project is massive in both cases.

Have you ever thought about offline builds that you can sign offline and upload to the download server? If you look at the current date of the binaries, then it's not about nightly builds anyway.
And have you ever thought about hosting the website and source code on an open source hosting platform like sourceforge? This would allow the build server to be used as isolated server independent from the rest.
And have you ever thought about reproducible builds?

bugmenot wrote: ↑Wed Sep 25, 2024 11:28 pm Your binaries can't be trusted.

Feel free to build KolibriOS images yourself, it's an open source project.

bugmenot wrote: ↑Wed Sep 25, 2024 11:28 pm There could also be an intention behind this, so that you could deny that Kolibri OS is used to distribute malware. Then you would still have an excuse and could say that you are not qualified to set up proper security. The damage to the project is massive in both cases.

The only reason is lack of resources. If you are ready to maintain the infrastructure you are talking about, you are welcome to do so. We all are volunteers.

bugmenot wrote: ↑Wed Sep 25, 2024 11:28 pm Have you ever thought about offline builds that you can sign offline and upload to the download server?

Sure. This would require each developer to set up the whole build server infrastructure. This isn't easy even for Linux hosts. For Windows it is even worse. In short, this approach won't work for a hobby project.

bugmenot wrote: ↑Wed Sep 25, 2024 11:28 pm If you look at the current date of the binaries, then it's not about nightly builds anyway.

They are automatic builds. The build is run automatically for each commit.

bugmenot wrote: ↑Wed Sep 25, 2024 11:28 pm And have you ever thought about hosting the website and source code on an open source hosting platform like sourceforge?

Well, Sourceforge is known for injecting adware into prebuilt binaries.

bugmenot wrote: ↑Wed Sep 25, 2024 11:28 pm And have you ever thought about reproducible builds?

Yes. Unfortunately, thinking is not enough. Your help is appreciated.

dunkaist wrote: ↑Thu Sep 26, 2024 12:12 am

bugmenot wrote: ↑Wed Sep 25, 2024 11:28 pm Your binaries can't be trusted.

Feel free to build KolibriOS images yourself, it's an open source project.

No, I simply won't use it at all. And since I can program in assembly language, but can't even test it due to the lack of a trustworthy source, I probably won't contribute anything to the project. What I definitely won't do is a code audit of the entire source code on my own. It would simply be too much work.

You should build a chain of trust with PGP signatures and commits early on. The lack of developers or resources is simply an excuse here, because that is standard and in the long term there will come a point where you will have to audit the entire code at once because you didn't do it in the past. Just like it happened with other open source projects because they didn't have a PGP chain of trust either in their early days. So what you are missing out on now will mean a multiplication of the work later. That's why you should do it right from the start.

That would be the advice I could give.

bugmenot wrote: ↑Wed Sep 25, 2024 11:28 pm Have you ever thought about offline builds that you can sign offline and upload to the download server?

Sure. This would require each developer to set up the whole build server infrastructure. This isn't easy even for Linux hosts. For Windows it is even worse. In short, this approach won't work for a hobby project.

That's nonsense. A build server might be helpful, but it's not a requirement for building source code. You can also set up a private build server as a VM on your desktop machine and distribute ready to use VM that do this job. And as already mentioned, the build server should be separated from the web server. Getting alternative webspace is easy.

bugmenot wrote: ↑Wed Sep 25, 2024 11:28 pm And have you ever thought about hosting the website and source code on an open source hosting platform like sourceforge?

Well, Sourceforge is known for injecting adware into prebuilt binaries.

This previously only affected Windows Installer and is a couple of years old. And if you sign your binaries, that can't happen anyway. It's just about having a different server for the download platform and the website, so that the build server can be independent. There are also other options than sourceforge. Gitlab and github, for example, but they have the problem that they require you to sign very long contracts just so you can register to do simple things, like reporting a bug, for example. That's why I suggested sf and not gitlab or github. The latter two should actually be avoided for this reason. Too much effort for nothing.

I agree that doing right things in the right way is the best. That said, we aren't starting from scratch: the project is about twenty years old now. It has its legacy, bugs, flaws, etc. In its code, in our infrastructure, in many aspects. I'm not trying to say you're wrong. We are putting our little efforts to push the project forward. Many great ideas, including yours, aren't implemented not because we don't understand or don't want them but because there is nobody to take this responsibility and put required amount of time and qualification. Some things seem to be easy only at the very first glance. Yes, 'getting alternative webspace' is easy and cheap. But who will commit to maintain it for years? You're welcome. But you want this to be done for you by somebody else. I hope this will happen one day.