Hello Samuel,
thank you for your reply.
On 07.06.21 17:16, Samuel Henrique wrote:
Control: severity -1 normal
Hello Jan,
Thanks for the detailed explanation and for pushing your integration
tests. I have pushed them[0] to the main repo (with the same changes
we discussed in the rsakeyfind MR) making use of the "-t 50"
parameter. So the package can have integ tests even before we get to
solve the problem, I hope you don't mind.
Absolutely not, thanks for merging!
It looks like it's not gonna be very easy to debug this, and
considering the way the package works[1], I'm lowering the severity to
normal and I'll likely not gonna try to fix it (anybody reading this
please feel free to submit MRs).
You could consider to raise the default threshold via a patch as a
workaround until the bug can be fixed.
What do you think of this proposal?
In order to debug this you will probably have to get a stacktrace for
two runs of aeskeyfind against the same dump file, one for each
version of glibc (or whatever is the suspect), and compare them to see
where's the difference in computation occurring for the xor variables.
This is gonna be quite complicated as those variables get changed
inside a loop (for the chunks of memory retrieved) and you're only
interested in one of those iterations (maybe the dump can be
simplified to contain only the key).
I bet it would be an interesting and cool investigation, but one would
have to have enough time for it, so don't feel pressured to do so, the
fact that you found the issue and contributed the integ tests already
put the package in a much better position.
Thanks for the hints. It seems to be challenging and time consuming,
indeed.
I will put it on my backlog, maybe I will find time to tackle it, but I
can't promise that.
If someone wants to tackle the issue, it would be great to keep us
updated here in this thread.
Best regards
Jan
