On 2021/03/25 20:53, Balder Oddson wrote: > On Thu, Mar 25, 2021 at 07:09:37PM +0100, Balder Oddson wrote: > > Compression in PPP was great in the age of ISDN to increase speeds. > > The more common use cases, and trends concerning TLS1.3 advancements. > > > > Having this enabled by default, and infrequently used could lead to > > unintended consequences around how the data is passed around. > > > Off list it has been suggested that this is ridiciolous. > And perhaps this is, especially for the justifications given, thought be > sufficient. > > From a UNIX architectural perspectiv, adhering to things like > "everything is a file". > > PPP device are not physical devices that can be used for a PPP > connection, where it is more trivial with a practice to do compression > and decompression before presenting the payload to the kernel so its > forced to go through the usual barriers. > > Back in the day, when everything was a PPP connection for most people, > this made good sense and also gave good performance. > > Having code in the kernel that is even better than say, base64 that can > detangle a malicious payload isn't the point here. There shouldn't be > targetable code in the kernel for these kinds of tasks that can be > exploited. And the task should preferably be something outside of kernel > space or in a real device driver.
I don't quite understand what you're saying here but it sounds like you're trying to remove one of the copies of libz is used so it can't be accessed from the kernel, is that it? What's the point, there are others? Do you want to remove hibernate as well? > Not having read the code, case in point on principle, I'm arguing that > there should be solid reasoning to enable it by default, as those with a > need for it can certainly enable it and build a kernel. It's not that simple, using a custom kernel means you can't use syspatches so are more likely to stay on a vulnerable version if a kernel bug is fixed. > Maybe this isn't a huge concern for the network parts of the code, but > as soon as there is multiprocessing and desktop applications involved, > it becomes increasingly unattractive. What's the technical reasons for > this code in 2020? > > option INET6 # IPv6 > > option IPSEC # IPsec > > -option PPP_BSDCOMP # PPP BSD compression > > -option PPP_DEFLATE > > +#option PPP_BSDCOMP # PPP BSD compression > > +#option PPP_DEFLATE # Disabled by default, TLS1.3 trends This comment doesn't make any sense > > option PIPEX # Ppp IP EXtension, for npppd > > option MROUTING # Multicast router > > option MPLS # Multi-Protocol Label Switching > > -- > Balder Oddson >
