3 ms·

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 han

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.

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.