@n3npq please, can you send Pull Request instead of attaching patches in
archive?
--
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/issues/197#issuecomment-293167567__
Attached is patch to extend RPMTAG_{BUILDTIME,INSTALLTIME,INSTALLTID} to add a
2nd element that contains a struct timespec tspec.tv_nsec 2nd element.
There are 2 new getters/setters added to the rpmts API: rpm{Get,Set}Tid2().
About the only subtlety (so far) is the need (for rpmdb "legacy compat
Blockchain can establish that an rpmdb event happened. That isn't enough
because a root kit can either fake an rpmdb event, or skip using blockchain to
register the event.
On a compromised system, any executable, including the tools used to track
installs, can be altered.
Creating a trusted 3
> Hmmm ... its not clear what exploit is used (from just reading the file at
> the URL you gave).
I think "DIZZYTACHOMETER" doesn't exploit anything itself, but is just hiding
e.g. a rootkit installation by manipulating the rpmdb based on already existing
write permissions gained before. I didn
Yes x32 has exactly the same issue. The RPM5 code for the resolver is very
different then this code set. So unfortunately it can't be directly applied.
I simply don't understand the conflict resolution loop in this code base enough
to understand why I'm not able to do the three-way resolution.
