Why iodé does not have reproducible images?
2 Likes
They did? Where can I see the doc’s on that?
Some information regarding hardware security:
1 Like
What we learn from the XZ-Utils backdoor incident? Never trust a binary:
As most of us cannot create their own hardware and cannot compile an OS from the source code, we have to rely on what is provided by a more or less trustworthy company.
Since the communication from GrapheneOS we know that France requires backdoors, similarly to the US and other countries. Hence IoddéOS has backdoors implemented. Usually companies are obliged to lie if they are asked about such backdoors, so asking directly does not help, as you can see in the answer of vince31fr.
Is this a no-go?
Well, yes. But what are the alternatives? Stock Android? GrapheneOS? Linux? LineageOS?
Stock Android is for sure worse than all other alternatives. GrapheneOS requires google hardware for a de-googled OS. I would not know any hardware which is Linux compatible. LineageOS may be an alternative, but may be quite basic, I never tried.
So finally I stay with IodéOS, at least for the next time, even knowing that it’s not secure.
1 Like
False. Propagating this statement does not make it true.
False. Propagating this statement does not make it true.
Each company does as it wants. We have a clear commitments towards our users. If such thing happened, we would either stop our activity, or be as clear as possible on what has been implemented. And I’ m pretty sure that ways of blocking what has been implemented would magically appear from (maybe anonymous) sources.
When facing an absurd reasoning based on false assumptions, I usually give absurd answers. Life is short and I wouldn’t miss a good occasion to laugh.
5 Likes
This is a good question, certainly the most interesting point in this thread. iodéOS builds can in principle be reproduced, but there are a number of difficulties. The main one is the state of the sources: when a release is made and the sources are uploaded to our gitlab, all repos are not pushed, because most of them are used untouched from their origin (mainly AOSP and LineageOS). However, no trace is kept of their current state used to produce the builds.
One option would be to push all repos to gitlab, but this would consume a lot of disk space, and it is also a good thing to fetch repos from their original place.
Another option would be to keep track of the HEAD of each repo, and checking out all repos to that registered state. This is something we can work on, for two reasons: (1) unofficial builders could use the exact source state that we used at each release (actually, they regularly have problems because some repos are updated here and there making them incompatible with the state needed to compile), and (2) because it would allow independent developers to check the binaries which are embedded in iodéOS builds.
We will work on this topic asap, and give instructions/scripts on how to reproduce our builds: this should give a clear STOP to that sterile polemics.
About source verification : please note that our changes wrt aosp/lineageos can be very easily checked, because at each release, we rebase on top of upstream repos. So one can easily check that the top upstream commit really exists in upstream, and have just to check all our commits from that point to the head of the repo.
10 Likes
Thanks for the answer.
For US companies it’s the reality having to implement backdoors for granting access to authorities. For other countries, e.g. China, this may apply too.
France is known as a force driving towards mass surveillance. French authorities forcing French software to implement backdoors appears plausible unfortunately, not absurd.
Btw.: I have the impression that GrapheneOS tries to undermine the reputation of IodéOS and other custom ROMs, see the fediverse thread below:
2 Likes
Really, you think ?
Now wish them a good life and lets forget about them.
I still find it absurd that a herd of humans adopts the unfounded reasoning of an elite, however charismatic and talented they may be on certain subjects, simply because unsubstantiated claims are stated loudly and often enough. In discussions like @andi reports, there’s often a little voice asking for evidences, never heard of course (which led to my ironic “The evidences” posts). Both past and recent history have unfortunately shown this to be true on many occasions; I won’t say any more, or we’ll end up directly at Godwin’s point[1]…
My first reaction to all this was to follow the well-known rule inherited from the old Usenet era: “Don’t feed the trolls.” Inevitably, people ask questions.
My second reaction was: “Why not laugh about it?” and share my amusement at the absurdity and satire. Still not enough.
My third reaction will be technical, since we have to get there. I can predict in advance that this will not be enough! But since it will bring real benefits (at least for unofficial builds, as previously explained), the task is worthwhile.
Implementing build reproducibility will probably require some effort and time[2], so don’t expect results too quickly. And I completely agree with @petefoth. The more time we spend on unproductive tasks, the less we improve the system, at everyone’s expense.
… sorry.
8 Likes
“What can be asserted without evidence can also be dismissed without evidence.“
Of course, it is beneficial for building a chain of trust when reproducible builds are created.
1 Like
Yes of course. What I don’t appreciate a lot here, is having to work on it because our integrity is being questioned, rather than just following a challenging suggestion aimed at making improvements.
Now, let’s dot it 
Edit: “questioned”: that way, and without a microscopic single beginning of evidence
4 Likes
Sadly, they have all the taxpayers’ money to taunt and provoke in forums here and there and discourage those who are volunteering or acting honestly from doing something good for those very taxpayers. Instead, they are worn down and the corporations continue to call the shots.
3 Likes
Providing technical solutions for concerns of potential technical issues is a good move.
Reproducible builds go into the right direction.
2 Likes
At risk of muddying the water, to clarify, you can already (and for a long time) build your own iodéOS version that would take current upstream(s) plus iodéOS specific code and produce your own build. This is already done by me, @petefoth , @ronnz98 and others to make “Unofficial” iodéOS builds (largely to support devices beyond what iodé officially supports).
But what makes reproducible builds hard, as Vincent more clearly explains above, is that as we integrate upstream sources at the time the build is created, a build of iodéOS 7.0 (official or unofficial) for a device made a few weeks after the first iodéOS 7.0 was built will be different due to the changes upstream in the meantime. You can use an iodéOS tag for the iodé specific code, but that doesn’t apply to the upstream LineageOS and possible vendor-issued source updates, those will be current as of build time.