Hello Adrian, hello Samuel,
My reading of the code is that it was intended to be
-t = set_byte(t, (j-1)%4, sbox[get_byte(k,j)]);
+t = set_byte(t, (j-1+4)%4, sbox[get_byte(k,j)]);
It's looking good, I have uploaded 1:1.0-10 to unstable, hopefully
this was the only issue still
Hello,
> My reading of the code is that it was intended to be
> -t = set_byte(t, (j-1)%4, sbox[get_byte(k,j)]);
> +t = set_byte(t, (j-1+4)%4, sbox[get_byte(k,j)]);
It's looking good, I have uploaded 1:1.0-10 to unstable, hopefully
this was the only issue still affecting other
On Sat, Jun 12, 2021 at 04:07:15PM +0100, Samuel Henrique wrote:
> Hello all,
>
> > The bug is trivial to fix, that's actually less work than all the
> > workarounds.
>
> I can't see how that's trivial so I would appreciate it if you could
> send a patch or describe what you're thinking of. I
Hello all,
> The bug is trivial to fix, that's actually less work than all the
> workarounds.
I can't see how that's trivial so I would appreciate it if you could
send a patch or describe what you're thinking of. I had tried a few
approaches but none of them worked out.
Cheers,
--
Samuel
On Fri, Jun 11, 2021 at 01:08:50AM +0100, Samuel Henrique wrote:
>...
> I'll reduce the set of archs we build aeskeyfind for to i386 and
> amd64, it's apparent we can't ensure that the package is working fine
> for our users on the other archs. Feel free to express your concerns
> if you disagree.
> The investment of the time in the autopkgtests was obviously not for
> nothing...
It gets even better...
debci is showing us[0] that aeskeyfind is broken both on armhf and arm64 [1][2].
I'm willing to bet both errors are coming from the reliance on
undefined behavior of aeskeyfind and that it
Hello Adrian,
hello Samuel,
great news!
On 10.06.21 03:50, Samuel Henrique wrote:
Hello all,
Everything about this bug looks like better compiler optimization
hitting code with a latent bug, and as expected using either gcc-9
or -O2 "fixes" the problem.
Glad, that you could identify the
Hello all,
> Everything about this bug looks like better compiler optimization
> hitting code with a latent bug, and as expected using either gcc-9
> or -O2 "fixes" the problem.
That's a great finding, thank's Adrian,
I have uploaded a workaround for this issue (removing the -O4 flag,
keeping
On Sun, Jun 06, 2021 at 10:18:34AM +0200, Jan Gruber wrote:
>...
> Therefore it looks like to me, that the error stems from some
> changes related to glibc 2.31-11 (or maybe even the kernel in Version
> 5.10.0.6).
>...
Everything about this bug looks like better compiler optimization
hitting
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
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
Hello Samuel,
On Sat, 29 May 2021 14:06:18 +0100 Samuel Henrique wrote:
>
> That's a great catch!
> I'm bumping the severity as this "makes the package in question
> unusable or mostly so".
thanks for getting back to me regarding this bug.
Since there is just an offset in the values used for
Control: severity -1 grave
Control: tags -1 moreinfo
Hello Jan,
That's a great catch!
I'm bumping the severity as this "makes the package in question
unusable or mostly so".
I believe you accidentally pasted the same link twice when talking
about two different functions.
Could you submit your
Package: aeskeyfind
Version: 1:1.0-8
Severity: important
Tags: upstream
Dear Maintainer,
I was in the process of creating autopkgtests for aeskeyfind and discovered,
that using aeskeyfind with kernel 5.10.0.6 and glibc 2.31-11 leads to wrong
results. Existing AES-keys are not found, although
14 matches
Mail list logo
