> > I'm concerned that re-implementing parts of rpm has the potential to double
> > the surface area for bugs. I get that writing code in C is more difficult
> > and error prone than other languages.
>
> This has generally been borne out to be true, so I generally will advocate
> for people to _not_ take the rpm-ostree/rpm-oxide approach, as it leads to
> broken user experiences.
The main reason rpm-oxide was written was the number of memory unsafety issues
found when I audited the librpm codebase, combined with the slow speed at which
they were patched. Qubes OS needed a solution that could protect it from
future vulnerabilities.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1470#issuecomment-860858121
_______________________________________________
Rpm-maint mailing list
[email protected]
http://lists.rpm.org/mailman/listinfo/rpm-maint
