On Thu, Jul 30, 2020 at 1:02 AM Philippe REYNES
<philippe.rey...@softathome.com> wrote:
>
> Hi Patrick
>
> > From: Patrick Oppenlander <patrick.oppenlan...@gmail.com>
> >
> > This meant that the order of operations had to change. If we replace the
> > data property first then fail to add the data-size-unciphered property
> > the data will be ciphered again when retrying.
>
>
> This patch is good, but I disagree with the comment. It is not mandatory
> to change the order of operation because when signing/ciphering we always
> start from "fresh" file.
>
> This "trick" is done in the function fit_handle_file(...)
>
> Just before the loop, the tmpfile is rename in bakfile
>
> sprintf(bakfile, "%s%s", tmpfile, ".bak");
> rename(tmpfile, bakfile);
>
> And in the loop, the first operation is to copy bakfile to tmpfile:
>
> for (size_inc = 0; size_inc < 64 * 1024; size_inc += 1024) {
> if (copyfile(bakfile, tmpfile) < 0) {
> printf("Can't copy %s to %s\n", bakfile, tmpfile);
> ret = -EIO;
> break;
> }
> ret = fit_add_file_data(params, size_inc, tmpfile);
> if (!ret || ret != -ENOSPC)
> break;
> }
>
> So I think that we always cipher with unciphered data.
>
Hi Philip,
I don't think that is the case if you use "mkimage -F". The input can
already be ciphered.
Patrick
