The Mobian project is uploading the majority of its packages into Debian already and the goal is to reach 100%.
At that point it will be only plain Debian.
Privacy&security trustworthiness-wise, Mobian is an unknown quantity (at least, to me).
That should be a big concern for something as sensitive as a smartphone/handheld, which tend to handle people's electronic communication, authentication for even more sensitive resources, etc.
One path to trust would be to become an official Debian project, and to be scrutinized by broader Debian people.
And the Mobian Team: 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.
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.
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.
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/ [2] 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.
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.
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.
There are still quite some packages that are not reproducible:
https://tests.reproducible-builds.org/debian/reproducible.ht...
If you look at the list, including some core packages such as gcc and Perl.
Reproducible builds are an additional safety net and you can easily check what differs between builds.
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.