Skip to content
This repository was archived by the owner on Mar 10, 2026. It is now read-only.

Prevent cert creation failure on leap day#5643

Closed
mattjohnsonpint wants to merge 1 commit into
apple:masterfrom
mattjohnsonpint:leap-year
Closed

Prevent cert creation failure on leap day#5643
mattjohnsonpint wants to merge 1 commit into
apple:masterfrom
mattjohnsonpint:leap-year

Conversation

@mattjohnsonpint

Copy link
Copy Markdown

The http_sspi_make_credentials function in cups/tls-sspi.c has a leap year bug.

cups/cups/tls-sspi.c

Lines 1968 to 1973 in bc5060a

GetSystemTime(&et);
et.wYear += years;
ZeroMemory(&exts, sizeof(exts));
createdContext = CertCreateSelfSignCertificate(hProv, &sib, 0, &kpi, NULL, NULL, &et, &exts);

This will fail if the code is executed on Feb 29th of a leap year (of which 2020 is the next one), unless the years being added also results in et.wYear being a leap year. In other words, 2020-02-29 + 1 year would result in 2021-02-29, which does not exist. In this case, CertCreateSelfSignCertificate will fail.

The attached PR checks for this condition, and adjusts such dates back one day to February 28th, which is a reasonable and common practice.

Please be sure this gets merged and highlighted in the release notes. Those that rely on this code path will want to have fully deployed such code well before leap day 2020. Thanks.

@michaelrsweet

Copy link
Copy Markdown
Contributor

FWIW, I'm not aware of too many users of libcups on Windows to provide an IPP server, but I'll make sure to include this fix in the next patch update...

@michaelrsweet

Copy link
Copy Markdown
Contributor

I opted for a simpler fix that avoids expiration dates on Feb 29th, no matter whether it is a leap year or not.

[master 6d391f7] Don't generate certificates that expire on Feb 29th (Issue #5643)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants