Bug 247607 - Installations don't include patches
Summary: Installations don't include patches
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: Unspecified
Hardware: Any Any
: --- Affects Many People
Assignee: FreeBSD Release Engineering
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-28 05:35 UTC by Adam Weinberger
Modified: 2021-07-24 19:37 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Weinberger freebsd_committer freebsd_triage 2020-06-28 05:35:01 UTC
When FreeBSD is downloaded from the website or installed through normal means, only -RELEASE is included. We want users to have the best experience out-of-the-gate, so we should update the installation media when new patches are released.

It also means that if users want to deploy a jail by extracting base.txz, they have to roll it themselves if I want the patches current.

Clearly it's unreasonable to provide media for every patch, but having two versions available (-RELEASE and the current -pX, defaulting to the -pX) would be a huge benefit to our users and ourselves.

Also, there's no reason for the updates to be atomic. It's reasonable to release patches right away, reroll amd64 shortly after that, and reroll the other archs gradually over the next few days.

Is this idea even feasible? Is this something that re could accomplish?
Comment 1 Adam Weinberger freebsd_committer freebsd_triage 2021-07-24 19:21:48 UTC
It's been a year since this PR was filed, so this is a ping.

This PR is about distributing fully patched downloads, rather than expecting all installations to run freebsd-update immediately. There's really no common circumstance under which a user would want an unpatched fresh FreeBSD installation.
Comment 2 Colin Percival freebsd_committer freebsd_triage 2021-07-24 19:37:20 UTC
I think the biggest reason to not do this is signatures -- releases are signed by the release engineer, who isn't necessarily involved with the process of issuing security updates.

It could be done after the fact by "unrolling" tarballs, applying updates, "rerolling" them, and then re-signing the files, but that seems like a lot of work compared to telling users to apply security updates after they install.

(I do have plans to provide pre-patched EC2 images, though, since the speed of getting a new system up and running is more important in cloud platforms.)