batched periodic updates with security 'fast-tracked', vs incumbent continous updates firehose
I see the ongoing disagreement as to approaches in the Fedora
FESCO bug, Adjust/Drop/Document batched updates policy [A],
and here. I think there is some ** common ground **, fairly
easy to implement, to satisfy both the: 'we need testing at
once' cohort, and the: 'we are bandwidth constrained, or
_churn_-adverse' group
I chipped in briefly in today's FESCO meeting, but wanted to
state a clean possible away forward
Background:
For updates, repodata is made by recursing a binary RPM tree
That binary RPM tree may contain matter which has been
indicated as security sensitive, and the rest not so
designated
Why not:
1. Continuously add to the binary RPM corpus (the present
practice)
2. THEN run a new post process, where a new directory (call it
'security' for the moment) is created via 'hardlinks' (so no
additional space requirements) (new)
3. If a given package is 'tagged' as security sensitive (put
to one side for a moment HOW to know), add a hardlink to that
new directory (new)
3a. Once the process is complete, run a 'repoclosure' test on
the 'security' directory, and additional hardlinks to satisfy
needed dependencies for those files, pulling from 'base' and
'updates' (similar to present practice)
4. Run a 'createrepo' on the 'security' directory, and name
the output something distinctive:
security-YMD
comes to mind (new)
5. Once a week for say, Tuesday, run a 'repoclosure' test on
the FULL directory (the present practice, but with a new
output name in a moment)
5a. Raise an exception if it fails such, and bail and carp
(the present practice)
6. If it passes, then run a 'createrepo' on the 'security'
directory, and name the output something distinctive:
patchTuesday-YMD
(new)
7. Push those two sets of repodata out async, or daily, under
the names (symlinks work here):
security
(new, so 'security' is always as fresh as possible with
repoclosure)
8. - and - ONLY weekly, update the link an updated last
successfully generated:
patchTuesday
(new)
[This has the effect of fast-tracking security matter, and
yet still having a pointer to the last known good complete
transaction set of general updates]
===========
9. Continue to run 'normal' repoclosure, and 'createrepodata'
processes. This is the full and continuous async 'updates'
archive (the present practice)
===========
10. Amend the yum.conf offerings to have reference, in
addition to 'updates', enabled and pointing to two new
stanza's in 'updates' called:
security
-and-
patchTuesday
(new but fully backward compatible)
===========
Use case narrative:
If one enables both regular 'updates' and the 'security' /
'patchTuesday' config file, one gets continuous updates. If
one disables regular 'updates' , one still gets updates, but
only security updates get fast-tracked. If one disables the
new stanza, one assumedly does not mess with 'updates' if one
cares about updates (so: new, but fully backward compatible)
----------
Sidenote:
Above, I put to one side how to ascertain that something is:
'tagged' as security sensitive
I would suggest that if an update is asserted to be security
sensitive, just add to the top Changelog entry: a tag with a
"[CVE YYYY-NNNN]" reference, or once any embargo has passed, a
tag with a "[Security]" reference and a pointer to the long
form description of the issue in play
It is trivial to extract the --changelog first stanza from a
package, and so scan it and branch accordingly, if such are
found, in building the 'security' hardlinked working copy
-- Russ herrold
A. https://pagure.io/fesco/issue/1820