Revert "Refactor: main: substitute is_auth_req macro"

[jfriesse]

This reverts commit da79b8b.

authfile != authkey

Signed-off-by: Jan Friesse jfriesse@redhat.com

Solves #114

[jfriesse]

@dmuhamedagic The reason for failing check is coverity which (after the patch) finally got a chance to go thru the code paths with hmac enabled and it found out that boothc header secs field is 32-bit

struct boothc_header {
...
uint32_t secs;  /* seconds */

and result of time_t (64-bit because of Y2K38 problem) is stored into 32-bit header (in init_header_bare). 2K38 is not so close, but it may be good idea to solve the problem anyway. Any idea how to solve the problem without breaking wire compatibility?

[dmuhamedagic]

Thanks! Unfortunately, I managed to confuse Jan (the other one) with the name.

[jfriesse]

@dmuhamedagic Thanks! Any idea about solving Y2K38 problem I've described in previous comment (#115 (comment))?

I had an idea - what about ignore fact that it is wall time and instead say it is 32-bit timestamp which can overflow - and we count with it by using sliding window? So (for example) cmp knows that 0 is bigger than uint32-1 at time uint32-2?

Would you accept such patch?

[dmuhamedagic]

On Thu, Jul 07, 2022 at 08:10:32AM -0700, Jan Friesse wrote: @dmuhamedagic Thanks! Any idea about solving Y2K38 problem I've described in previous comment (#115 (comment))?

I didn't miss it, but at the time had no good idea what to do about it. Still don't.

I had an idea - what about ignore fact that it is wall time and instead say it is 32-bit timestamp which can overflow - and we count with it by using sliding window? So (for example) cmp knows that 0 is bigger than uint32-1 at time uint32-2? Would you accept such patch?

Of course. Sounds good.

[jfriesse]

On Thu, Jul 07, 2022 at 08:10:32AM -0700, Jan Friesse wrote: @dmuhamedagic Thanks! Any idea about solving Y2K38 problem I've described in previous comment (#115 (comment))?
I didn't miss it, but at the time had no good idea what to do about it. Still don't.

Oh .. ok :) No worries

I had an idea - what about ignore fact that it is wall time and instead say it is 32-bit timestamp which can overflow - and we count with it by using sliding window? So (for example) cmp knows that 0 is bigger than uint32-1 at time uint32-2? Would you accept such patch?
Of course. Sounds good.

I will try to prepare patch - still not sure if it will really work so maybe I find out different approach is needed... Let's see.