4 ms·

While yes, it is not strictly a Debian project, there is significant overlap between the Debian on Mobile team: https://salsa.debian.org/DebianOnMobile-team htt

by kop316 5y ago

While yes, it is not strictly a Debian project, there is significant overlap between the Debian on Mobile team: https://salsa.debian.org/DebianOnMobile-team https://salsa.debian.org/DebianOnMobile-team And the Mobian Team: https://gitlab.com/mobian1 https://gitlab.com/mobian1 Debian packaging has a nice feature too in that you can check the source used to build it, and any of the packages will be reproducible. So if you don't trust any of the Builds on the Mobian repository, you can actually check them all yourself.

vineyardmike 5y ago
> you can actually check them all yourself For any sufficiently large project, this becomes basically infeasible unless you have serious resources or known risks to account for. "You can check the source" is almost a meme - how many people check the source of stuff they use? Likely very few. Most depend on history of trust and audits, and well funded groups paying people check.
- kop316 5y ago
  In learning the Debian Packaging, I have a LOT more confidence in the Debian Packaging process, and a much better understanding of why it is what it is. Debian packaging (the quilt format) will watch the upstream git repo and will error out if the repo being packaged is different than what is upstream. The only way to add patches is to put them into the "Debian/Patches" folder and explicitly put them in there. In addition, one of the default CI pipelines for the Gitlab called "reprotest", which checked various environment differences to ensure that the package is reproducable. The outcome of this is it is signifiantly easier to check that a downstream package matches upstream for the average person, rather than checking all of the source, they can look at where upstream points to and check if reprotest passes.
  - danieldk 5y ago
    You are ignoring the main point of the grandparent. Even excluding the possibility that an upstream is compromised. Who is going to check all the patches by hand in debian/patches? If someone is going to insert vulnerabilities, they are probably going to hide it well as an innocent-looking patch. So, you need a C security expert. Moreover, they probably need to do this work full-time to inspect every patch, since you do not really know what you are looking for. As the recent covert introduction of vulnerabilities in the Linux kernel [1] and Debian OpenSSL incident [2] have shown, catching patches that introduce vulnerabilities is hard. [1] https://lwn.net/Articles/853717/ https://lwn.net/Articles/853717/ [2] https://lwn.net/Articles/282038/ https://lwn.net/Articles/282038/ At any rate, I think the approach taken is fine. The project is actively upstreaming changes to Debian. But if you care about security, etc., it is probably better to wait until the changes have landed in Debian and you can install vanilla Debian.
    - kop316 5y ago
      > You are ignoring the main point of the grandparent. Respectfully, I do not think so. I went into great detail about how Debian has technical measures to prevent tampering from upstream. If one does not trust upstream programs....well that is a bit out of scope of this issue. > Who is going to check all the patches by hand in debian/patches? By policy, we only introduce patches there if it is absolutely necessary, so there actually aren't very many assuming you really want to. I'd argue its a tractable problem. > But if you care about security, etc., it is probably better to wait until the changes have landed in Debian and you can install vanilla Debian. As I said earlier, many of the Mobian devs are the same as the Debian on Mobile team, so assuming you don't trust the Mobian devs, you probably shouldn't trust the packages we put in Debian proper as well.
      - vineyardmike 5y ago
        > If one does not trust upstream programs....well that is a bit out of scope of this issue. This was actually the whole point. People say "trust us because you can check the code" but checking the code is so complex that you need trust because you can't verify everything. > As I said earlier, many of the Mobian devs are the same as the Debian on Mobile team, so assuming you don't trust the Mobian devs, you probably shouldn't trust the packages we put in Debian proper as well. This is where the trust comes in. Not in the availability of the code.
danieldk 5y ago
Debian packaging has a nice feature too in that you can check the source used to build it, and any of the packages will be reproducible. So if you don't trust any of the Builds on the Mobian repository, you can actually check them all yourself. There are still quite some packages that are not reproducible: https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht... If you look at the list, including some core packages such as gcc and Perl.
- goodpoint 5y ago
  All packages in Debian are peer reviewed by Debian Developers and the package/build/upload process is transparent. Reproducible builds are an additional safety net and you can easily check what differs between builds.
  - danieldk 5y ago
    You are setting up a strawman [1]. I reacted to the grandparent who stated: Debian packaging has a nice feature too in that you can check the source used to build it, and any of the packages will be reproducible. Which is demonstrably false, as the link in my comment shows. [1] I never said that packages are not peer-reviewed.

by kop316 5y ago

vineyardmike 5y ago

> you can actually check them all yourself For any sufficiently large project, this becomes basically infeasible unless you have serious resources or known risks to account for. "You can check the source" is almost a meme - how many people check the source of stuff they use? Likely very few. Most depend on history of trust and audits, and well funded groups paying people check.

kop316 5y ago
In learning the Debian Packaging, I have a LOT more confidence in the Debian Packaging process, and a much better understanding of why it is what it is. Debian packaging (the quilt format) will watch the upstream git repo and will error out if the repo being packaged is different than what is upstream. The only way to add patches is to put them into the "Debian/Patches" folder and explicitly put them in there. In addition, one of the default CI pipelines for the Gitlab called "reprotest", which checked various environment differences to ensure that the package is reproducable. The outcome of this is it is signifiantly easier to check that a downstream package matches upstream for the average person, rather than checking all of the source, they can look at where upstream points to and check if reprotest passes.
- danieldk 5y ago
  You are ignoring the main point of the grandparent. Even excluding the possibility that an upstream is compromised. Who is going to check all the patches by hand in debian/patches? If someone is going to insert vulnerabilities, they are probably going to hide it well as an innocent-looking patch. So, you need a C security expert. Moreover, they probably need to do this work full-time to inspect every patch, since you do not really know what you are looking for. As the recent covert introduction of vulnerabilities in the Linux kernel [1] and Debian OpenSSL incident [2] have shown, catching patches that introduce vulnerabilities is hard. [1] https://lwn.net/Articles/853717/ https://lwn.net/Articles/853717/ [2] https://lwn.net/Articles/282038/ https://lwn.net/Articles/282038/ At any rate, I think the approach taken is fine. The project is actively upstreaming changes to Debian. But if you care about security, etc., it is probably better to wait until the changes have landed in Debian and you can install vanilla Debian.
  - kop316 5y ago
    > You are ignoring the main point of the grandparent. Respectfully, I do not think so. I went into great detail about how Debian has technical measures to prevent tampering from upstream. If one does not trust upstream programs....well that is a bit out of scope of this issue. > Who is going to check all the patches by hand in debian/patches? By policy, we only introduce patches there if it is absolutely necessary, so there actually aren't very many assuming you really want to. I'd argue its a tractable problem. > But if you care about security, etc., it is probably better to wait until the changes have landed in Debian and you can install vanilla Debian. As I said earlier, many of the Mobian devs are the same as the Debian on Mobile team, so assuming you don't trust the Mobian devs, you probably shouldn't trust the packages we put in Debian proper as well.
    - vineyardmike 5y ago
      > If one does not trust upstream programs....well that is a bit out of scope of this issue. This was actually the whole point. People say "trust us because you can check the code" but checking the code is so complex that you need trust because you can't verify everything. > As I said earlier, many of the Mobian devs are the same as the Debian on Mobile team, so assuming you don't trust the Mobian devs, you probably shouldn't trust the packages we put in Debian proper as well. This is where the trust comes in. Not in the availability of the code.

danieldk 5y ago

Debian packaging has a nice feature too in that you can check the source used to build it, and any of the packages will be reproducible. So if you don't trust any of the Builds on the Mobian repository, you can actually check them all yourself. There are still quite some packages that are not reproducible: https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht... If you look at the list, including some core packages such as gcc and Perl.

goodpoint 5y ago
All packages in Debian are peer reviewed by Debian Developers and the package/build/upload process is transparent. Reproducible builds are an additional safety net and you can easily check what differs between builds.
- danieldk 5y ago
  You are setting up a strawman [1]. I reacted to the grandparent who stated: Debian packaging has a nice feature too in that you can check the source used to build it, and any of the packages will be reproducible. Which is demonstrably false, as the link in my comment shows. [1] I never said that packages are not peer-reviewed.