I don't agree with any of these reasons. These limits have been considered carefully. At this time, there is no known justification for someone in the 'network admin' role to change any of them.
We do not know what a future 'emergency' would look like, but I doubt it would look like "oh I know, I want to change this specific maximum'. I'm sorry, but I don't believe software should be infinitely reconfigurable in complex ways. If people hit real problems, they need to communicate within the culture and have the experts not just reconsider the limits, but also these various self-defense mechanisms they are part of, and in most cases code will get rewritten, not just some number. Jeroen Massar <[email protected]> wrote: > (chiming in from the sidelines) > (TLDR: Use a scary looking env variable instead.) > > > On 20211126, at 24:50, Theo de Raadt <[email protected]> wrote: > > > > [..] > > There are huge benefits to having a userbase running with the same > > choices. I don't see evidence that throw that away, by giving them > > options which encourage fragmented usage patterns. > > I mostly agree with that. > > Though.... for emergency cases, it might be quicker for people to be able > to set a documented but otherwise obscure environment variable that has big > warnings that one should normally not set that, than recompiling code > they have not recompiled in a while and afterward might not upgrade. > > A command line option has less of a "don't change" feeling to it as that > makes it an option. > > Naming it the overlong RPKICLIENT_EMERGENCY_MAX_REPO_PER_TAL environment > variable will dissuade people from changing it (and if they do, their choice) > while avoiding having to recompile code (and then having a custom built not > being upgraded with syspatch the next update) > > Same goes for the portable edition, where the distribution's maintainer might > override the value because "we know better, there was an emergency once" or > who then implements that code, badly, themselves. > > (At least we have Marco d'Itri taking care of Debian packages and he would > no do that, but the possibility still exists ;) > > Greets, > Jeroen >
