On Tue, Nov 01, 2022 at 04:15:03PM -0700, Stewart Smith via devel wrote: > Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> writes: > > See: https://lists.freedesktop.org/archives/systemd-devel/2022-October/048519.html > > > > Systemd will set the taint flag 'support-ended' if it detects that > > the OS image is past its end-of-support date. This date is declared > > in a new /etc/os-release field SUPPORT_END= described below. > > > > [...] > > > > os-release gained a new field SUPPORT_END=YYYY-MM-DD to inform the user > > when their system will become unsupported. > > > > > > Should we set this? I kind of think we should. > > Yes! > > We have started to set it in Amazon Linux 2022, and likely will at some > point do so in prior versions as well (even though they all use older > than 252 versions of systemd). Hi, I'm happy to hear that you're already making use of this ;) Just to reply to the part about older releases: I think it'd be totally fine to add the metadata to an older release in an update. The tooling to actually make use of this information may even be external (e.g. something looking _into_ a container or some other image), and may make use of without the system _in_ the release caring about the field. > This is very much so we can get as much information as possible into > machine readable formats for security tooling to be able to read. > > > I would suggest we set it to the expected EOL based on the nominal schedule. > > We could either release updates to extend it if we slip... or... just not do > > that. > > The update is a rather small and unobtrusive one, and in our experience > of doing updates to our system-release package (equivalent of > fedora-release), we've managed to not cause any negative customer issues > with modifications to it that weren't functional in some way > (e.g. switching default repository setup to https endpoints rather than http) +1 Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
