Hi Claudio,
I've picked up a manifest file from
rsync://rpki-repository.nic.ad.jp/ap/A91A73810000/131/L8CZI7Bafo8a3ZpZhO3BkyDbl0s.mft
The original version returned (i'm at BRT/GMT-3)
~/tmp/rpki-client/test-mft -fv L8CZI7Bafo8a3ZpZhO3BkyDbl0s.mft
test-mft: L8CZI7Bafo8a3ZpZhO3BkyDbl0s.mft: before date interval (clock
drift?)
Then I recompiled with the patch
~/tmp/rpki-client/test-mft -fv L8CZI7Bafo8a3ZpZhO3BkyDbl0s.mft
Subject key identifier:
EE:5D:98:F8:26:D1:CB:74:51:66:33:19:CF:0A:3D:07:93:16:0B:73
Authority key identifier:
2F:C0:99:23:B0:5A:7E:8F:1A:DD:9A:59:84:ED:C1:93:20:DB:97:4B
1: 0ZTSWTHKM6DAI-7X7vKA4Dsl0QA.roa
2: CEWdZa_wPWlIQFjORnCFsISzzDU.roa
3: DFkQyvXRONF1IbHjMuKJg6ba9cQ.roa
4: DbWquhW0v3em_pNviWFlwF7gvew.roa
5: L8CZI7Bafo8a3ZpZhO3BkyDbl0s.crl
6: W-2EIMQvUkht96ZljxZUZaXrK1g.roa
More details about this mft:
EE Certificate
===============================================================================================
Version: 3
Serial: 0B
Issuer:
/CN=2FC09923B05A7E8F1ADD9A5984EDC19320DB974B
Subject:
/CN=EE5D98F826D1CB7451663319CF0A3D0793160B73
Not Before: 2019-08-27 08:27:42 UTC
Not After: 2020-06-19 08:41:09 UTC
Subject Info Access:
rsync://rpki-repository.nic.ad.jp/ap/A91A73810000/131/L8CZI7Bafo8a3ZpZhO3BkyDbl0s.mft
Subject key identifier:
EE:5D:98:F8:26:D1:CB:74:51:66:33:19:CF:0A:3D:07:93:16:0B:73
Authority key identifier:
2F:C0:99:23:B0:5A:7E:8F:1A:DD:9A:59:84:ED:C1:93:20:DB:97:4B
Manifest
=====================================================================================================
Manifest Number: 1771
This Update: 2019-10-17 09:50:00 UTC
Next Update: 2019-10-17 15:50:00 UTC
605f9f2aabffcb4836c1de1162f5e45dceea7d231e8141fc5e6545dda978be02
0ZTSWTHKM6DAI-7X7vKA4Dsl0QA.roa
437c82214bb75aa0fafd68b42f84c790d2f3408021123ebd1af4896dd41bbcd0
CEWdZa_wPWlIQFjORnCFsISzzDU.roa
5511d23b3927e6b388c518ea742fea889c581c27b457f1cd89fcef7d9bbb3b65
DFkQyvXRONF1IbHjMuKJg6ba9cQ.roa
2134e5ecb8484bc45bdaf45d94f5476311ead9d9321aa2d8930b402810442199
DbWquhW0v3em_pNviWFlwF7gvew.roa
85f385500f59a47782e6bd970d507f8345199576be0db7a74fbfcce4162cb62b
L8CZI7Bafo8a3ZpZhO3BkyDbl0s.crl
71c701bf391c6d65cf9527bab7c0e5344851f658f175314e7cfadfd6ec1e9485
W-2EIMQvUkht96ZljxZUZaXrK1g.roa
Regards,
Alexandre Hamada
On 17/10/2019 08:47, Claudio Jeker wrote:
On Thu, Oct 17, 2019 at 08:07:18AM -0300, Alexandre Hamada wrote:
Hi Claudio,
Thanks for this, much appreciated.
This is a much cleaner solution, I really liked it.
I've tested both versions against a brand new manifest, and it is working
well.
Thanks for testing. Did you manage to trigger warnings with the original
version (the one using mktime())? I was not really abel to trigger them
but my guess is that CEST is just to close to GMT.
One thing about this patch, at mft_parse_econtent() there are some unused
variables left (this, next, now and buf[64]).
Good point. I removed them in my tree.
Thanks again and regards,
Alexandre Hamada
On 16/10/2019 17:47, Claudio Jeker wrote:
On Wed, Oct 16, 2019 at 07:26:25AM -0300, Alexandre Hamada wrote:
Hi Tech,
I would like to suggest to use UTC functions on all date/time convertions,
to avoid some clock drift errors.
Kind regards,
Alexandre Hamada
https://patch-diff.githubusercontent.com/raw/kristapsdz/rpki-client/pull/9.patch
From a463f8cb23375f15b74eff49a06e8934423e3dbf Mon Sep 17 00:00:00 2001
From: dev-gto <43351700+dev-...@users.noreply.github.com>
Date: Wed, 16 Oct 2019 07:22:46 -0300
Subject: [PATCH] Avoid local time conversion
---
mft.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mft.c b/mft.c
index f9176b4..738f3ff 100644
--- a/mft.c
+++ b/mft.c
@@ -75,8 +75,8 @@ gentime2time(struct parse *p, const ASN1_GENERALIZEDTIME *tp)
memset(&tm, 0, sizeof(struct tm));
if (strptime(buf, "%b %d %T %Y %Z", &tm) == NULL)
errx(EXIT_FAILURE, "%s: strptime", buf);
- if ((t = mktime(&tm)) == -1)
- errx(EXIT_FAILURE, "%s: mktime", buf);
+ if ((t = timegm(&tm)) == -1)
+ errx(EXIT_FAILURE, "%s: timegm", buf);
return t;
}
Hi Alexandre,
How about this diff instead. This is inspired by OCSP_check_validity() and
uses ASN1_GENERALIZEDTIME_check() and X509_cmp_time() to do the validity
check. I think this has a way better chance to produce the expected
results. My quick testing seems to indicate that it works but review and
testing is very welcome.
