On Thu, Feb 08, 2018 at 09:05:50PM +0100, Philip Hands wrote: > On Thu, 08 Feb 2018, Julian Andres Klode <j...@debian.org> wrote: > > Hey guys, > > > > APT will shortly start validating that the Date field in a release > > file is not (too far) in the future. This might have implications > > for installing on devices with an inaccurate clock, as they might > > now fail. > > > > There are two primary workarounds: > > > > * Set Acquire::Check-Date to false > > * Set check-date sources.list option to false > > It is probably worth checking the system's current time to see if it is > before the date that apt was built (or rather apt's SOURCE_DATE_EPOCH) > and/or the date that the medium that is being booted was built (if > that's available) or similar, to check if we're living in the past.
relevant IRC quote: <juliank> Of course, we can also only enable that feature if the current time is beyond the APT release time. <juliank> (the source epoch thingy) <juliank> "Your clock is too far beyond, disabling verification of release file dates" <weasel> eek > > If that's the case, these errors about future signatures are really not > worth reporting. > > It might also be good to then try hard to get sensible time somehow, but > that's not apt's problem to solve. Perhaps the right thing to do in d-i > is to check for being in the past, try to find a decent time source, and > if that fails then set a flag that could be used to decide to disable > the check when we come to running apt. AFAIUI, d-i tries very early to get time via ntp. If it fails, it should probably write a file and then set the check-date option to false. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
