[SOLVED] Is there CI for official packages?

jronald · 2024-04-07 03:15:32

I'd like to monitor the procedure of testing as much as possible.

Last edited by jronald (2024-04-08 04:59:33)

Allan · 2024-04-07 03:25:26

No

jronald · 2024-04-07 03:33:32

So is the procedure like this?
1. someone build installers(.zst) locally
2. updateload them to the official repo for public use

If it is true, how to make sure that the binaries are safe?

Last edited by jronald (2024-04-07 03:36:23)

skunktrader · 2024-04-07 04:40:48

jronald wrote:

If it is true, how to make sure that the binaries are safe?

You could participate in the testing

jronald · 2024-04-07 04:48:18

skunktrader wrote:

You could participate in the testing

How does participation in testing make sure that it is safe?
Is there a chance to modify the code after testing and before building the final package?

Allan · 2024-04-07 06:33:07

https://wiki.archlinux.org/title/Reproducible_builds

jronald · 2024-04-07 07:31:09

Allan wrote:

https://wiki.archlinux.org/title/Reproducible_builds

Reproducibility is useful, but it's not practical for an average user to take so much time to reproduce every binary, and that will be like "Linux From Scratch".
If the building procedure is totally open (like github actions), I think it's a good start.

Last edited by jronald (2024-04-07 08:08:28)

Allan · 2024-04-07 08:26:42

You really don't have to reproduce every binary. You can look at the status page and see which packages are reproducible.

Trilby · 2024-04-07 13:09:38

jronald wrote:

So is the procedure like this?
1. someone build installers(.zst) locally
2. updateload them to the official repo for public use
If it is true, how to make sure that the binaries are safe?

Not quite. Many / most packages go into the [testing] repository for a bit before being moved to the main repo.

But what do you really mean by "safe" in these contexts? You say that testing software cannot prove software is safe, and that's certainly true. But you started this thread only asking about "CI" which does far far less to ensure safety.

You've now stated that you are not interested in testing the built software, you are not interested in building the software, and your goals are not addressed by reproducible builds. Instead of telling us all the things that don't meet your needs, how about you just tell us what your needs are? What do you mean by "safe"? Safe from what? Safe for what?

"Continuous Integration" as it's normally defined is simply nonsensical in the context of packaging software: there are not a bunch of developers writing code for the same final binary. Continuous integration (as normally defined) might apply to some upstream sources, not to packaging. Of course if you define it more broadly just as where the work of many people is assembled for testing before broader release, then yes, we have that - it's called the testing repos (which you've said you're not interested in).

Last edited by Trilby (2024-04-07 13:40:59)

progandy · 2024-04-07 13:56:19

If you mean CI simply in the form of tests that run during the build, then some packages provide a check()-function that runs tests provided by upstream and aborts packaging if the test fails. There are no public logs about their results and packagers may choose to skip running them.

That doesn't have anything to do with safety either, just that the packaged program is able to perform some specific tasks without error.

jronald wrote:

So is the procedure like this?
1. someone build installers(.zst) locally
2. updateload them to the official repo for public use
If it is true, how to make sure that the binaries are safe?

If "safe" means the packager did not modify the public source code, then that can be verified using the reproducible builds. The official rebuilder runs on infrastructure provided by arch. If you do not trust that, you'll have to find others or run your own to ensure that the source code was not modified to build the package that is provided in the repository.

Last edited by progandy (2024-04-07 14:00:41)

jronald · 2024-04-07 14:54:48

@Trilby @progandy

Trilby wrote:

But what do you really mean by "safe" in these contexts?

progandy wrote:

If "safe" means the packager did not modify the public source code, then that can be verified using the reproducible builds. The official rebuilder runs on infrastructure provided by arch. If you do not trust that, you'll have to find others or run your own to ensure that the source code was not modified to build the package that is provided in the repository.

This is exactly what I mean about "safe". I trust the official rebuilder, does the official packages used by "pacman" are built by the official rebuilder? Or is the official rebuilder only for verification by checking the reproducibility?

Last edited by jronald (2024-04-07 14:55:52)

Trilby · 2024-04-07 15:22:54

I believe official packages can be build on whichever machine the packager wishes. Is there any reason to trust the rebuilder more than the packagers - other than minimizing the number of trusted entities?

jronald · 2024-04-07 15:39:47

Trilby wrote:

I believe official packages can be build on whichever machine the packager wishes. Is there any reason to trust the rebuilder more than the packagers - other than minimizing the number of trusted entities?

Generally when the rebuider and the input of it are both open, the result should be trustable.
Take github for example, compare the two cases:
1. The releases are generated automatically by "github actions"
2. The releases are built and uploaded by the author
Which one is more trustable? I think the former one is.

Last edited by jronald (2024-04-07 15:47:44)

Trilby · 2024-04-07 16:21:32

jronald wrote:

Generally when the rebuider and the input of it are both open, the result should be trustable.

The input used by the packager is "open" too. But I'm not sure what you mean by the rebuilder being open. Is there a rebuilder-rebuilder to confirm that the rebuilder is indeed what it is supposed to be? No, you just trust the team that set up the rebuilder server. And that's fine - but why trust that team, and not the packaging team?

I don't really use github. So that comparison is a bit lost on me. But I find it odd given news over the past year or so that you'd use github as an example of a trustworthy source.

Last edited by Trilby (2024-04-07 16:22:43)

jronald · 2024-04-08 02:47:12

Trilby wrote:

The input used by the packager is "open" too. But I'm not sure what you mean by the rebuilder being open. Is there a rebuilder-rebuilder to confirm that the rebuilder is indeed what it is supposed to be? No, you just trust the team that set up the rebuilder server. And that's fine - but why trust that team, and not the packaging team?
I don't really use github. So that comparison is a bit lost on me. But I find it odd given news over the past year or so that you'd use github as an example of a trustworthy source.

Compare the 2 cases:
1. input -> man -> output
2. input -> builder -> output

Man is dynamic, he himself may change (e.g. good today, bad tomorrow), and he might be replaced by another one oneday.
Comparatively the builder is static.
A static one is possible to be verified, a dynamic one is not.

Last edited by jronald (2024-04-08 04:49:05)

Allan · 2024-04-08 03:25:51

Fedora has a single builder for their packages. Can you verify it? I don't mean theoretically. In practise, is it possible to verify?

This is the entire point of reproducible builds. Arch does quite well in this regard:
https://reproducible.archlinux.org/

jronald · 2024-04-08 04:59:15

Allan wrote:

Fedora has a single builder for their packages. Can you verify it? I don't me theoretically. In practise, is it possible to verify?
This is the entire point of reproducible builds. Arch does quite well in this regard:
https://reproducible.archlinux.org/

Reproducibility is the way, thanks.

Arch Linux

#1 2024-04-07 03:15:32

[SOLVED] Is there CI for official packages?

#2 2024-04-07 03:25:26

Re: [SOLVED] Is there CI for official packages?

#3 2024-04-07 03:33:32

Re: [SOLVED] Is there CI for official packages?

#4 2024-04-07 04:40:48

Re: [SOLVED] Is there CI for official packages?

#5 2024-04-07 04:48:18

Re: [SOLVED] Is there CI for official packages?

#6 2024-04-07 06:33:07

Re: [SOLVED] Is there CI for official packages?

#7 2024-04-07 07:31:09

Re: [SOLVED] Is there CI for official packages?

#8 2024-04-07 08:26:42

Re: [SOLVED] Is there CI for official packages?

#9 2024-04-07 13:09:38

Re: [SOLVED] Is there CI for official packages?

#10 2024-04-07 13:56:19

Re: [SOLVED] Is there CI for official packages?

#11 2024-04-07 14:54:48

Re: [SOLVED] Is there CI for official packages?

#12 2024-04-07 15:22:54

Re: [SOLVED] Is there CI for official packages?

#13 2024-04-07 15:39:47

Re: [SOLVED] Is there CI for official packages?

#14 2024-04-07 16:21:32

Re: [SOLVED] Is there CI for official packages?

#15 2024-04-08 02:47:12

Re: [SOLVED] Is there CI for official packages?

#16 2024-04-08 03:25:51

Re: [SOLVED] Is there CI for official packages?

#17 2024-04-08 04:59:15

Re: [SOLVED] Is there CI for official packages?

Board footer