> Please do not drag Go into this if you want to handwave Go away > problems. Yes modules will be useful in Go but only to blow away in EPEL > the rotten Go codebase RHEL ships. > > But anyway, since you referred to GO. > > Go is the perfect example of why bundling as a general approach does not > work and does not scale. In case you haven't noticed years of bundling > Go side has resulted in such a deep widespread rot Google is scrambling > to write a Go v2 language version that will force Go projects to version > and update. > > All the people that claim bundling allows “using a slightly older > version” (implying it's a good safe maintained older version) are lying > through their teeth. Yes it allows doing that but that's not how people > use it. And it does not matter if you bundle via self-provided windows > DLLS, containers, flatpacks, modules or rhel versions. > > Bundling basically allows reusing third party code blindly without any > form of audit or maintenance. You take third party code, you adapt your > code to its current API, and you forget about it. > > You definitely *not* check it for security legal or other problems, you > definitely *not* check regularly if CVEs or updates have been released, > you definitely *not* try to maintain it yourself. Any bundler dev that > tells you otherwise lies. The average bundler dev will tell you “Look at > my wonderful up to date award-wining modern code, security problems? Ah, > that, not my code, I bundle it, not my problem”. > > It is however a *huge* problem for the people on the receiving end of > the resulting software, static builds or not. Static builds do not add > missing new features or fix security holes. They just remove the shared > libs that could be used by the sysadmin use to track them. And since > malware authors do not bother identifying how software was compiled, > before attempting to exploit it, static builds do not hinder them the > slightest. > > While trying to improve Go packaging in Fedora by myself I found serious > old security issues in first-class Go code. First-class as in benefiting > from huge publicised ongoing dev investments from major companies like > Google, Red Hat or Microsoft. It’s not hard, you do not even need to > write Go code, just take the bundled pile of components those bundle, > and read the upstream changelog of those components for later versions. > You will hit pearls like “emergency release because of *** CVE”. Or > “need to change the API to fix a race in auth token processing”. And the > answer of the projects that bundled a previous state of this code was > never “we have a problem” or “we have fixed it some other way” but “go > away, we haven’t planned to look or touch this code before <remote > future>”. > > And, again, I’m no Go dev, or dev in general, I didn’t even try any form > of systematic audit, that was just the bits jumping to attention when I > hit API changes and had to look at the code history to try to figure > when they occurred. The day any bundled codebase is subjected to the > kind of herd security research java was some years ago and CPUs are > today sparks are going to fly all over the place. > > And this is a natural phenomenon trivial to explain. Maintaining old > code versions is hard. Upstreams are not interested in supporting you. > You have to redo their work by yourself, while forbidding yourself API > changes (if you were ready to accept them you wouldn't have bundled in > the first place). And modern code is so deeply interdependent, freeze > one link in the dependency web and you get cascading effects all other > the place. You quickly end up maintaining old versions of every single > link in this web. If you try to do it seriously, you effectively have to > fork and maintain the whole codebase. IE all the no-support problems of > barebones free software, with none of the community friends help that > should come with it. > > That's what RH tries to do for EL versions. It takes a *huge* dev > investment to do in a semi-secure no-new features way. And after a > decade, RH just dumps the result, because even with all those efforts, > it reaches terminal state and has no future. > > There is only one way to maintain cheaply lots of software components > that call each other all over the place. That’s to standardise on the > latest stable release of each of them (and when upstream does not > release, the latest commit). And aggressively port everything to the > updates of those versions when they occur. If you are rich, maintain a > couple of those baselines, maximum. flatpackers do not say otherwise > with their frameworks (except I think they deeply underestimate the > required framework scope). > > And sure, every once in a while, porting takes consequent effort, it can > not be done instantaneously, devs are mobilized elsewhere, etc. That's > when you use targeted compat packages, to organise the porting effort, > to push the bits already ported while keeping the ones not ready yet. > And to *trace* this exception, to remind yourself that if you do not fix > this you’re going to be in deep trouble and get in old code maintenance > hell. > > Not porting is not an “optimization”. Not porting is pure unadulterated > technical debt. Porting to upstream API changes *is* cheaper > than freezing on an old version of upstream’s code you get to maintain > in upstream’s stead. > > If you try to use modules as a general release mechanism, and not > temporary compat mechanisms, you *will* hit this old code maintenance > hell sooner than you think. Not a problem for RH, old code maintenance > is basically the reason people pay for RHEL, huge problem for Fedora. > > Because bundling has never been a magic solution. It’s only a magic > solution when you are the average dev that does not want to maintain > other people’s code, nor adapt to this other people’s code changes. > > One bonus of bundling is removal of any kind of nagging that would > incite the dev to take a look at what happens upstream, so he can sleep > soundly at night. > > But the real bundling perk is that, because container and static build > introspection tech is immature, you get to *not* *maintain* the code you > ship to users, with bosses, security auditors, etc being none the wiser. > Force any bundler dev to actually maintain all the code he ships, and I > can assure you, his love affair with bundling will end at once. > > Regards, > > -- > Nicolas Mailhot ++ awesome write up of thing that we have been facing in the Go packaging for few years already. I hope that with the joint forces Go-SIG will be able to improve the situation. JC > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
