rhboot / rhboot/shim

Why is it not necessary to determine a common year or a leap year here

Open
#752 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
1.1k
Forks
348
PR merge metrics
No merged PRs in 30d

Description

Hi all,

For the BOOLEAN EFIAPI ConvertAsn1TimeToEfiTime (IN ASN1_TIME *Asn1Time, OUT EFI_TIME *EfiTime) interface in Cryptlib/Pk/CryptTs.c, I have some questions.

EfiTime->Month = (Str[Index++] - '0') * 10;
EfiTime->Month += (Str[Index++] - '0');
if ((EfiTime->Month < 1) || (EfiTime->Month > 12)) {
return FALSE;
}

EfiTime->Day = (Str[Index++] - '0') * 10;
EfiTime->Day += (Str[Index++] - '0');
if ((EfiTime->Day < 1) || (EfiTime->Day > 31)) {
return FALSE;
}

Here, the validity of EfiTime->Day is not checked based on EfiTime->Month and EfiTime->Year. For instance, when EfiTime->Month is 2, EfiTime->Day in a common year should not exceed 28, and in a leap year, it should not exceed 29. When EfiTime->Month is 4, EfiTime->Day should not exceed 30.

Why is it only necessary to check whether EfiTime->Day is between 1 and 31 here? Could anyone help explain this? Thank you

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read Cryptlib/Pk/CryptTs.c and inspect ConvertAsn1TimeToEfiTime, focusing on the month, day, and year parsing shown in the issue. Check whether validation is handled elsewhere or whether this path accepts impossible calendar dates; done means documenting the rationale or defining the required validation behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
operating-systems
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.