4 ms·

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

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

by kop316 5y ago

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.