Your message dated Sun, 4 Jul 2021 22:29:47 +0200
with message-id <YOIaO/[email protected]>
and subject line Re: Bug#989918: unblock: aeskeyfind/1:1.0-11
has caused the Debian Bug report #989918,
regarding unblock: aeskeyfind/1:1.0-11
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
989918: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989918
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: release.debian.org
User: [email protected]
Usertags: unblock
X-Debbugs-Cc: [email protected]
Severity: normal
Please unblock package aeskeyfind
[ Reason ]
The recent introduction of integration tests, thanks to Jan Gru <
[email protected]> uncovered two critical issues with aeskeyfind:
1. A somewhat recent regression caused by compiler's change and
aeskeyfind's code with undefined behavior
2. Failure to retrieve AES keys on a non-corrupted memory dump for archs
arm64, armhf and ppc64el (integration tests only pass for amd64 and i386).
Problem 1 is fixed by a patch provided by Adrian Bunk <[email protected]> and
problem 2 is mitigated by disabling the other archs (restricting it to
amd64 and i386).
More details at the bugreport:
https://bugs.debian.org/989179
[ Impact ]
aeskeyfind will fail to fulfill its only purpose of finding AES keys on
memory dumps.
[ Tests ]
The new integration tests allowed us to identify the issues in the first
place.
[ Risks ]
Since aeskeyfind is also used to recover AES keys out of corrupted memory
dumps, it **could** be possible that our fix for the non-corrupted scenario
broke the detection for corrupted dumps. I'm very confident that this
cannot be the case because of the way aeskeyfind looks for keys; without
the fix it was still possible to retrieve the key by making use of the
threshold (-t 50) parameter (which tweaks the heuristics of the algorithm).
The fix allows us to use the default threshold value (-t 10) which means
the algorithm gets the key with more confidence.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock aeskeyfind/1:1.0-11
aeskeyfind_1.0-11.debdiff
Description: Binary data
--- End Message ---
--- Begin Message ---
On 2021-06-16 12:38:13 +0200, Graham Inggs wrote:
> Control: tags -1 + moreinfo
>
> Hi Samuel
>
> As can be seen in aeskeyfind's excuses [1]:
>
> not blocked: has successful autopkgtest
>
> You'll need to file a RoM; ANAIS bug against ftp.debian.org [2]
> requesting removal of aeskyfind's binaries on the architectures where
> it no longer builds.
> Please close this bug, or remove the moreinfo tag once the removals
> have been done, if aeskeyfind still needs aging.
The old binaries were removed and the package should be able to migrate
on its own tonight or tomorrow.
Cheers
>
> Regards
> Graham
>
>
> [1] https://qa.debian.org/excuses.php?package=aeskeyfind
> [2] https://wiki.debian.org/ftpmaster_Removals
>
--
Sebastian Ramacher
signature.asc
Description: PGP signature
--- End Message ---
