[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#989918: marked as done (unblock: aeskeyfind/1:1.0-11)

Your message dated Sun, 4 Jul 2021 22:29:47 +0200
with message-id <YOIaO/xonN9h5D4L@ramacher.at>
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 owner@bugs.debian.org
immediately.)


-- 
989918: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989918
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
User: release.debian.org@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: samueloph@debian.org
Severity: normal

Please unblock package aeskeyfind

[ Reason ]
The recent introduction of integration tests, thanks to Jan Gru <j4n6ru@gmail.com> 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 <bunk@debian.org> 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

Attachment: 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

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: