From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 6236B77D73 for ; Thu, 29 Apr 2021 10:33:38 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5094F188DF for ; Thu, 29 Apr 2021 10:33:08 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id C9C5D188D4 for ; Thu, 29 Apr 2021 10:33:07 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 921C746367 for ; Thu, 29 Apr 2021 10:33:07 +0200 (CEST) To: Wolfgang Bumiller Cc: Proxmox Backup Server development discussion References: <20210422140213.30989-1-w.bumiller@proxmox.com> <20210422140213.30989-6-w.bumiller@proxmox.com> <20210429070110.7pngjgt4656nuyln@wobu-vie.proxmox.com> <20210429071414.3ufaqkjclbpgwnxy@wobu-vie.proxmox.com> From: Dietmar Maurer Message-ID: Date: Thu, 29 Apr 2021 10:33:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210429071414.3ufaqkjclbpgwnxy@wobu-vie.proxmox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-SPAM-LEVEL: Spam detection results: 0 AWL 0.362 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH v2 backup 05/27] CertInfo: add not_{after, before}_unix X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 08:33:38 -0000 On 4/29/21 9:14 AM, Wolfgang Bumiller wrote: > On Thu, Apr 29, 2021 at 09:08:03AM +0200, Dietmar Maurer wrote: >> On 4/29/21 9:01 AM, Wolfgang Bumiller wrote: >>> On Thu, Apr 29, 2021 at 08:13:19AM +0200, Dietmar Maurer wrote: >>>> Seems I can do it without foreign-types: >>>> >>>> fn asn1_time_to_unix(time: &openssl::asn1::Asn1TimeRef) -> Result>>> Error> { >>>>     let epoch0 = openssl::asn1::Asn1Time::from_unix(0)?; >>>>     let diff = epoch0.diff(time)?; >>>>     let seconds = (diff.days as i64) * 24*60*60 + (diff.secs as i64); >>>>     Ok(seconds) >>>> } >>>> >>>> Any objections? >>> Yes, for 2 reasons: >>> * openssl does provide the functionality and the dependency is already >>> in our tree because openssl pulls it in >>> * 1100 days in already covers 3 leap seconds and I don't want to worry >>> about whether `diff.days` takes that into account, the best time math >>> is no time math at all >> Agreed, but your code is unsafe and hard to read. IMHO that whole >> foreign_type thing is hard to understand. And Unix Epoch does not care about >> leap seconds, so why should we do? > Because the diff method doesn't give you a unix epoch, it gives you a > number of days without context which originally come from calendar > dates, and this way days aren't well-enough defined for my taste. Beside, it seems we do not need those methods at all if we return the tlme as String in the API. Returning time as String is better anyways, because it shows whats encoded inside the cert. For example. on my host: # openssl x509 -in /etc/proxmox-backup/proxy.pem -noout -text|grep After             Not After : Sep  2 13:45:56 3019 GMT If it convert to epoch and print that I get: 3019-09-02T15:45:56+02:00 We loose the original time zone info, so this is not optimal.