In days of yore (Sun, 31 Mar 2024), Colin Watson thus quoth: > On Sun, Mar 31, 2024 at 10:10:42AM +0200, Sirius wrote: > > Not worth boiling the ocean over, but is there an estimate of how many > > packaged projects have customisations to their autoconf that is not found > > in the upstream autoconf project? If that number is low single digit > > percent, it may motivate those projects to upstream their modifications. > > If it is double digits percent, it might not be possible to disallow > > vendoring the files. > > This is difficult to answer because it's comparing apples and oranges to > some extent: not all autoconf customizations are vendored or would make > any kind of sense to upstream. For example, > https://gitlab.com/man-db/man-db/-/blob/main/m4/man-arg-config-file.m4 > is obviously specific to that project; it's just in a separate file for > the same reasons that projects past a certain size don't typically put > all their code in a single file. > > I suspect the question you're aiming for is something like "how many > packaged projects have copied autoconf macros from elsewhere and > modified them but kept the same file names, so that a naïve attempt to > update them would drop those modifications". My guess is that the > number here is very low - IME it's much more common in such cases to > either rename the macro file to be obviously project-specific or to find > some workaround that doesn't require changing the upstream macro - but > I've never seen anything resembling a robust analysis of this and I may > well have a skewed view.
I find this interesting, even if it is a question that simply does not have a reasonable answer unless one goes and does the audit. Your rephrasing is actually closer to what I was aiming at - but that opens another question that may not have a reasonable answer: Would throwing away these unmodified (?) macros packaged projects may be carrying for hysterical raisins in favour of just using the autoconf native macros reduce the attack-surface a potential malicious actor would have at their disposal, or would it simply be a "putting all eggs in one basket" and just make things worse? And by how much vis-a-vis the effort to do it? I think that what I am trying to get at is this: is there low-hanging fruit that for minimal effort would disproportionately improve things from a security perspective. (I have an inkling that this is a question that every distribution is wrestling with today.) My apologies if I am asking too many questions. It has been a long time since I was using Debian (2004), but I am standing up environments and looking at how I may be able to put some of my sparse spare time to good use. So I am looking to learn (by doing) how to package things. I am building my own .deb of mutt (because I want a few things that the official package does not have) but am looking for "the right way" to do it. Just because I built it and it is running does not mean I have done it right. :-) -- Kind regards, /S
