On Tue, 28 Jan 2020 at 13:49, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > > On Tue, Jan 28, 2020 at 01:08:11PM -0500, Stephen John Smoogen wrote: > > On Tue, 28 Jan 2020 at 13:01, Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > > > > > > "Richard W.M. Jones" <rjones@xxxxxxxxxx> writes: > > > > > > > I always think that Fedora works fine if you maintain 1-5 packages. > > > > It's possible to maintain 20 with a lot of work. And if you want to > > > > maintain 100+ (things like the ocaml-* set that I help to maintain) > > > > then you have to write your own automation. Could we do things > > > > better? No one asked for them, but here are my ideas ... > > > > > > > > --- > > > > > > > > * CVE bugs should autoclose when a package is rebased > > > > > > > > Fabiano built the mingw-openssl package recently, but there are still > > > > a load of open CVE bugs against this package referring to the older > > > > version. These should be closed automatically. I think this will > > > > require collecting the version of the package that fixes a CVE and > > > > recording that in Bugzilla (or in the package itself in some standard > > > > way). > > > > > > This is an interesting idea, and I appreciate you're considering ways to > > > resolve this problem. However, I'm concerned that this will lead to > > > maintainers not actually checking whether a version fixes an issue - > > > since we don't have automatic verification (or even usually manual > > > verification) of security fixes, that wouldn't get caught. > > > > > > > You are assuming that maintainers actually check to see if a version > > fixes an issue already. If a packager has 100's or 1000's of > > packages.. there is no way they will have done so except on a 1 in a > > million case set. I think if are going to aim that a packager can > > 'maintain' hundreds or thousands of packages that we also assume that > > this security is not going to be checked by the maintainer. If it > > needs to be checked it will need to be 'outsourced' to some group who > > can do so. > > Also the bit where I said > "(or in the package itself in some standard way)." > > Of course that standard way doesn't exist (or does it?) but we could > surely encourage upstreams to provide data that we need in a standard > format, especially if we coorperate with Debian, SUSE, Arch and others. > > For example, for my upstream projects I write release notes (!= the > changelog) but they're text files and not really in any standard > location or format. Also we have security bug pages but again not in > a standard way. > > If it was standardized we could suck that data straight into Fedora > and no packager, whether maintaining 1 or 100 packages, would have to > be troubled by this. > My main concern is that we have been coming up with 'standard' proposals for 20 years and we can't seem to get more than any 4 maintainers to agree to what that means... even if they do the same work in Debian/SuSE/Arch etc. Too many idiosyncratic techniques which they use to keep themselves sane or working in whatever environments they have. At this point, I will take whatever we can standardize on even if it is clay tablets mailed to Babylon (ok maybe something a little less archaic) -- Stephen J Smoogen. _______________________________________________ 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
