This is where I put all the things I've created which I hope may somehow be useful to others.
I believe in modular, purpose-built software. The more freely a program or library can be adapted and joined to other software the better. This of course begs the question of interoperability, documentation and cooperation amongst developers, and is why I am a sharp proponent of free software. I cannot stress how important it is, not simply just for myself (in that regard I find it to be an unparalleled educational tool), but rather for humanity as a whole. It is the actualization of creating software without constraints of intellectual ownership/micromanagement.
I have a strong interest in distributed software systems, especially favoring self-healing networks and distributed data structures and associated techniques. Beyond that I prefer to create purpose-built, practical use applications in a variety of languages. Practical in that their sole use isn't to pad a resume, but rather be of some use to others now and in the future beyond direct use even, either for design ideas or coding practices. Being able to riddle off a list of intangibles for the sole purpose of creating a list reeks of convenience, if nothing else. Above all else, I would hope what I have created can be of some use to people, even if only pedagogical.
In retrospect, I have since come to understand that I am a very design-driven developer, perhaps even over designing at times. A vast majority of my effort is prepaid out beforehand designing multiple approaches and ideas. Generally this pays off since perfect information about the task at hand rarely exists (so much for SCRUM), and I'd rather fall back on a secondary design than have to re-design again on the fly. Over-designing also helps the implementation in terms of knowing what you'll expect out of certain parts of the program. Despite modern languages offering an over-abundance of higher-order constructs, I honestly don't believe in their liberal use, ie. Php's magic methods. Most of the highly extrapolated capabilities of modern languages are more reliably implemented by means of lower level controls. Illustratively, one could implement an alternative, and more highly-tailored form of reflection in any language that doesn't support it by means of status accessor methods. Judgment calls will inescapably need to be made about any design decision and in some cases these constructs can be indispensable, however a rush to be highly reflexive/dynamic isn't always the best approach, as readability can suffer.
Keywords: Apache2, Upload Limit, Request Limit, 1 GB, Lua, idealism.
I have been using apache since forever. So I tend to take things the wrong way when it gets mucked-with.
So, on a recent ugrade bender while changing some decade-old systems from the 3. kernel to something recent, and leaving ubunster to come back to debian all over again, I realized something odd.
There was definatley something blocking me from POSTing more than 1024MB files or even multiple smaller ones adding up to over that limit! This was to controlled code, code which I had worked out all kinks time and time again, and I knew exactly what needed to be adjusted in php.ini. No this was elsewhere, it wasn't even getting to php, and was in some browsers manifesting as a "413 request entity too large".
The usual gamut of sites and know-it-alls proved pretty much useless. Stuck in the past they were, perpetually hashing out the memory_limit and post_max_size existentialisms. Quickly I started the process of elimination, taking into account working systems with almost-as-new setups. It must, I deduced, be something 'Changed' in the last year or two and definately apache based. A flashback quickly befel me. Ahh right! Just like when PHP 8 decided (itself) to implicitly set the default timezone to UTC (and not use the system time)! It was a subtle but not TOO difficult change to notice. This one must be similarly situated. A long-standing apache2.conf setting that's never needed to be used has now had its default setting altered to 1 GiB, implicitly. But why?
🎡🌴🗿 CVE-2022-29404 🗿🌴🎡
So IF you're using LUA on the backend via Apache mod_lua and a malicious script...I'll let the official explanation stand:
In Apache HTTP Server 2.4.53 and earlier, a malicious request to a lua script that calls r:parsebody(0) may cause a denial of service due to no default limit on possible input size.
So to recap, to fix the issue, which can of course be mitigated by not using mod_lua as stated elsewhere or possibly implementing a script check manually which would parse potential user-generated scripts to look for the rparsebody(0) or perhaps rewriting the implemntation of rparsebody() to not accept unbounded inputs, instead ALL installations of the webserver WHETHER OR NOT THEY ARE USING LUA, must now have a decades-old convention changed (WITH NARY A NOTICE IN SUPPLIED apache2.conf FILES!) to a value which induces behavior which is VERY timeconsuming to track down given the multitude of competing settings in php or other backend solutions which mimmic the same situation, while at the same time affording the admin ZERO error log notices in a vanilla log installation that the situation is occurring. Oh, the fix could also have just been an alternative "LimitRequestBody" directive in mod_lua's conf which it could have been required to use. The possibilities are endless. What shouldn't have happened though is what did happen.
The REAL issue is how this fix is somehow considered an ideal resolution to the initial CVE at hand. Fixes should always address the problem as close to the original cause as possible. Something in a mod_lua config would have been much more appropriate to those of us luddites who don't use the module.