New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What to improve in ReaR project as lesson learned from XZ Attack? #3202
Comments
I find in particular this one interesting: https://mastodon.social/@AndresFreundTec/112208281684931915 From my point of view the most important outcome in that discussion is this
I.e. take out the "who" part from finding a solution Another posting in that discussion also indicates
I.e. trying to solve the "who" part via a "web of trust" From my personal point of view this means: New code that is not easy to understand should be Old code that is known to be OK since ages can stay as is. Simply put: So in the end from my personal point of view https://github.com/rear/rear/wiki/Coding-Style i.e. not some nitpicking coding syntax style "rules"
|
An important aspect is to meet the active contributors once personally. A "web of trust" should be a "people of trust" (in our case). All ReaR contributors have met each other in person - that helps. |
In addition to enforce that code must be easy to understand This means that all code changes But I think that a certain kind of slowness is helpful In practice enforced code change reviews means I mean only actual code changes (at least for now). E.g. typo fixes in comments can still be directly merged |
@gdha But: This would exclude people in far away countries. And it does not help when the account |
As mentioned already mentioned before all Pull Requests must be reviewed by another person then the author, and I would like to add an additional third person - the co-called "approver" of the PR. This way there always 3 persons involved before a PR is getting merged. |
We can enable branch protection to help us "remember" the PR rule, although maintainers of course can override that. I'm against a 6-eyes approval, at least now, because I think that going from "just do it" to "everything via PR" is already a big and probably sometimes inconvenient step for us. As we don't have any actual problem, I'd like to take this slowly, step by step. And inspect and adapt after every change. |
I also think that 6-eyes approval is too much for us for now. I always prefer to change things slowly, step by step. In think for now it is enough to have some kind of "enforced" Perhaps we should "enforce" approval by at least With "enforce" I mean that we set up something in GitHub FWIW: |
Perhaps, the biggest danger is not in the source code itself, but in the produced ISO images stored on a NAS location where everybody (within a company) can replace it with a malicious code (or whatever evil). |
Yes, that is however by design and we shouldn't worry about it. Maybe Secure Boot with custom keys can be used to create end-end secured DR boot media |
With this issue here I meant only our source code, Regarding secure ReaR recovery system images: |
FYI: https://news.opensuse.org/2024/04/12/learn-from-the-xz-backdoor/ |
For background information about the XZ Attack see
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
and follow the links therein, in particular see
https://tukaani.org/xz-backdoor/
and
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
The text was updated successfully, but these errors were encountered: