Re: A question about Security Advisories
Roger Marquis <[email protected]>
| Newsgroups | gmane.os.freebsd.security.general |
|---|---|
| Message-ID | <[email protected]> |
The SMUP (single monolithic update procedure) was implemented several years ago IIRC. At the time it was explained that there were insufficient staff resources to continue doing QA for incremental builds, even ones as simple as usr.bin/gzip. That said it is still just as straightforward to it yourself. What I wonder is why staff is so resource constrained? Is it fundamentally due to a broken funding model? Are potential volunteers turned away for not having submitted enough patches and other questionable policy hurdles? Are there other organizational reasons why such burdensome upgrades are left for end-users? A lot of this maintenance hassle will someday be resolved with base packages but even that project has been resource constrained. The FreeBSD Foundation has not, to the best of my knowledge, commented on these resource constraints or potential resolutions. Quarterly and Annual reports occasionally mention them but only in passing. How do we get someone on the Board/Foundation who is willing and able to prioritize these important issues? Roger Marquis >> Hi, >> Last years all Security Advisories regarding base system in the "update >> your vulnerable system via a source code patch " section recommends to >> rebuild a whole world instead of an affected part of a base system. This >> is in a most cases an overhead. >> >> For example 9 years old SA-11:04 [1] offers: >> >> b) Execute the following commands as root: >> >> # cd /usr/src >> # patch < /path/to/patch >> # cd /usr/src/usr.bin/compress >> # make obj && make depend && make && make install >> # cd /usr/src/usr.bin/gzip >> # make obj && make depend && make && make install >> >> What is a reason we stop to do it? I understand that the preferred way >> now is a binary upgrade. > > +1 I've been wondering this as well. What is the reason for it? > -- > J. > _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"