fix: reject expiration timestamp 0 and accept far-future timestamps in getEventExpiration() - #708
Conversation
…n getEventExpiration()
🦋 Changeset detectedLatest commit: 6785319 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
|
||
| const expirationTime = Number(rawExpirationTime) | ||
|
|
||
| if (Number.isSafeInteger(expirationTime) && Math.log10(expirationTime) < 10) { |
There was a problem hiding this comment.
Thanks for the PR! The Math.log10(0) fix is a genuine improvement.
|
@Priyanshubhartistm To be clear this isn't on you. 2038–2286 already fails on main for the same reason, the old @cameri i think your ms-scale concern still holds, just at a lower ceiling. |
|
@Priyanshubhartistm Flip the two far-future tests to expect undefined and add one for Actual year-9999 support needs |
…allows-zero' into fix/event-expiration-validation-allows-zero
|
@Anshumancanrock , thanks for tracing it through to the column type pushed a fix that caps at 2147483647 to match the actual expires_at int4 column, and flipped/added the tests accordingly. Agreed the year-9999 case is a separate bigint migration; happy to have that tracked as its own issue rather than bundled here |
Description
getEventExpiration()insrc/utils/event.tsusedMath.log10(expirationTime) < 10as a bounds check on the NIP-40expirationtag. This has two bugs:Math.log10(0) === -Infinity, which is< 10, so an expiration of0(Unix epoch) was accepted as valid.> 9,999,999,999) failed the< 10check and was silently discarded, treated as "no expiration."Replaced the check with
expirationTime > 0, which accepts any positive safe integer and rejects non-positive values, with no arbitrary digit-count ceiling.Related Issue
Closes #707
Motivation and Context
An expiration of
0should never be treated as a valid future expiration, and a relay shouldn't silently ignore legitimate (if far-future) expiration timestamps just because they cross an arbitrary digit-count boundary.How Has This Been Tested?
test/unit/utils/event.spec.tsunder the existingNIP-40 > getEventExpirationsuite:expiration: '0'→undefinedexpiration: '10000000000'(year 2287+) → returned as-ispnpm run test:unit(1395 passing) andpnpm run test:cli(73 passing)pnpm run lint,pnpm run check:deps,pnpm run build,pnpm run verify:cli:build,pnpm run cover:unit— all pass.Screenshots (if appropriate):
N/A — pure logic fix, no UI/API surface change.
Types of changes
Checklist: