Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018) • Hacker News Board

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#91

Post by ferzul » Thu, Mar 19, 2020, 11:26 PM UTC

michaelmrose wrote: post #54

sheepdestroyer wrote: post #32

Earlier quoted context omitted.

ZFS is not user land. It's kernel code but without being in the kernel. So it has to be built separately and may not even be compliant with GPL (still has to be tested in court AFAIK). Linux's promise to not break userspace is just that, It can not be held responsible for code that should be in the kernel but does not play fair with the license.

It's not that it doesn't play fair. Sun published under a license that made inclusion in the kernel impossible thus the current developers are bound by the same decisions regardless of their opinion on the matter. Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux be…

> Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking.

please don't confuse the source code and the resulting binaries. to the extent that the zsh source code does not derive from Linux, it is not a derivative work.

but the binaries built for Linux will necessarily be derivative of both.

and we regularly redistribute binaries; this indeed is what Linux distributions ordinarily do.

if you only write the bridging code and/or distribute the module source, you may be quite protected. but if you distribute a patch from the mainline to include zsh, or a mixed tarball of Linux+zsh, or even compiled Linux kernels complete with a loadable zsh module, you may be in breach. all of these clearly derive from multiple sources with incompatible licences.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#92

Post by ferzul » Thu, Mar 19, 2020, 11:34 PM UTC

zokier wrote: post #87

asveikau wrote: post #7

There's no reason why someone can't get their act together and fix ifconfig, or if that is insurmountable, rewrite it while maintaining the same outward appearances. I think this is not specific to Linux at all, and is not really about kernel ABI. This is a problem I see a lot, often in proprietary software too. Firstly, people opt to rewrite before they fix or even before they fully understand the old thing. Secondl…

> There's no reason why someone can't get their act together and fix ifconfig, or if that is insurmountable, rewrite it while maintaining the same outward appearances. But it's telling that nobody stepped up and actually bothered to do that despite all the bitching and moaning. Successful code is generally produced to solve problems, not fullfil some abstract ideals

some one in this very thread said did in fact do exactly that, since they needed compatibility with FreeBSD.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#93

Post by comex » Thu, Mar 19, 2020, 11:34 PM UTC

zokier wrote: post #87

asveikau wrote: post #7

There's no reason why someone can't get their act together and fix ifconfig, or if that is insurmountable, rewrite it while maintaining the same outward appearances. I think this is not specific to Linux at all, and is not really about kernel ABI. This is a problem I see a lot, often in proprietary software too. Firstly, people opt to rewrite before they fix or even before they fully understand the old thing. Secondl…

> There's no reason why someone can't get their act together and fix ifconfig, or if that is insurmountable, rewrite it while maintaining the same outward appearances. But it's telling that nobody stepped up and actually bothered to do that despite all the bitching and moaning. Successful code is generally produced to solve problems, not fullfil some abstract ideals

Except someone did rewrite it:

https://news.ycombinator.com/item?id=22628938

But with the Linux ecosystem's inertia being what it is, rather than the 2 existing implementations of ifconfig in use being displaced by this better one... now there are just 3 implementations of ifconfig in use.

As mentioned in the Stack Exchange thread linked in that post, a different someone submitted a relevant patch to one of those existing implementations – way back in 2013. But it was never accepted. More inertia.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#94

Post by internalthief » Thu, Mar 19, 2020, 11:41 PM UTC

Phemist wrote: post #76

JdeBP wrote: post #10

It's not quite that simple. People actually tried to update net-tools ifconfig (one of the two ifconfigs back in 2018). In 2019, I simply wrote an ifconfig that uses the netlink API, because for portability I needed a Linux ifconfig that had a FreeBSD-like command-line syntax. It doesn't have the old interface aliasing mentioned in the headlined article, and has no problems setting up and reporting IPv6 addresses or…

Off-topic: I can't help but be nosy and check the https version of your page. You seem to be serving a cert with CN=albertstreetantiquescentre.co.uk. Might want to get this looked at :) Edit: Interesting, https://jdebp.uk has the correct cert configured, whereas https://jdebp.uk . serves the cert as mentioned above.

It seems that the server running on the other end doesn't properly match the certificate from the SNI if the domain sent by the browser is a FQDN (i.e. ends in a .)

For example, try the following:

  openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk."

vs

  openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk"

You'll notice that in the first case the default certificate is sent back, in the second case the certificate is correctly matched against the SNI.

According to the Server header returned:

  Server: Apache/2.4.41 (cPanel) OpenSSL/1.1.1d mod_bwlimited/1.4 Phusion_Passenger/5.3.7

Testing against an NGINX based server, I am not seeing the same results, in fact I am seeing the correct certificate being returned.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#95

Post by tialaramex » Thu, Mar 19, 2020, 11:42 PM UTC

Phemist wrote: post #76

JdeBP wrote: post #10

It's not quite that simple. People actually tried to update net-tools ifconfig (one of the two ifconfigs back in 2018). In 2019, I simply wrote an ifconfig that uses the netlink API, because for portability I needed a Linux ifconfig that had a FreeBSD-like command-line syntax. It doesn't have the old interface aliasing mentioned in the headlined article, and has no problems setting up and reporting IPv6 addresses or…

Off-topic: I can't help but be nosy and check the https version of your page. You seem to be serving a cert with CN=albertstreetantiquescentre.co.uk. Might want to get this looked at :) Edit: Interesting, https://jdebp.uk has the correct cert configured, whereas https://jdebp.uk . serves the cert as mentioned above.

So, firstly don't put a dot at the end. Whatever you might feel about it, the decision in practice was that the host part of the URL is an FQDN but doesn't need a dot at the end. So don't write one there. The browser should probably trim it out when you type in or follow such a link.

The Apache web server that the bulk host is using for that site has a fairly poor implementation of HTTPS. It's unsatisfactory in various ways, some very technical, but what you're seeing here is the weird way it handles SNI.

By default when you say you want jdebp.uk. and there is no such virtual host (there's only jdebp.uk with no trailing dot) Apache will pick a default virtual host and act as though you asked for that, sending over the certificate for that host and so on. In this case, at a bulk hosting site, it's some unrelated Antiques Shop outfit, likely because that begins with 'A' which is the first letter of the alphabet.

This actually caused a problem for Let's Encrypt because their tls-sni-01 challenge type assumed nobody would be crazy enough to answer queries for a random name with a certificate chosen by somebody else entirely. But that's exactly what Apache is doing here. The current tls-alpn-01 challenge was introduced to fix that - it asks for a reserved ALPN service instead of a spurious SNI server name.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#96

Post by internalthief » Thu, Mar 19, 2020, 11:42 PM UTC

JdeBP wrote: post #79

Phemist wrote: post #76

Earlier quoted context omitted.

Off-topic: I can't help but be nosy and check the https version of your page. You seem to be serving a cert with CN=albertstreetantiquescentre.co.uk. Might want to get this looked at :) Edit: Interesting, https://jdebp.uk has the correct cert configured, whereas https://jdebp.uk . serves the cert as mentioned above.

That's the page on a shared hosting service, not served by me. See the site history page (still in the same place that it was a couple of years ago when it came up on Hacker News).

It's due to Apache not correctly matching the SNI when it is sent a FQDN ending in a period (.)

More information: https://news.ycombinator.com/item?id=22632959

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#97

Post by tialaramex » Thu, Mar 19, 2020, 11:43 PM UTC

internalthief wrote: post #94

Phemist wrote: post #76

Earlier quoted context omitted.

Off-topic: I can't help but be nosy and check the https version of your page. You seem to be serving a cert with CN=albertstreetantiquescentre.co.uk. Might want to get this looked at :) Edit: Interesting, https://jdebp.uk has the correct cert configured, whereas https://jdebp.uk . serves the cert as mentioned above.

It seems that the server running on the other end doesn't properly match the certificate from the SNI if the domain sent by the browser is a FQDN (i.e. ends in a .) For example, try the following: openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk." vs openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk" You'll notice that in the first case the default certificate is sent back, in the second case t…

The relevant RFC says not to send a trailing dot in SNI. Browsers should probably trim the dot out if present. Maybe they aren't doing so because it causes some unexpected compatibility mishap, maybe in reality it rarely causes any trouble so nobody got around to it.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#98

Post by aidenn0 » Fri, Mar 20, 2020, 12:03 AM UTC

michaelmrose wrote: post #54

sheepdestroyer wrote: post #32

Earlier quoted context omitted.

ZFS is not user land. It's kernel code but without being in the kernel. So it has to be built separately and may not even be compliant with GPL (still has to be tested in court AFAIK). Linux's promise to not break userspace is just that, It can not be held responsible for code that should be in the kernel but does not play fair with the license.

It's not that it doesn't play fair. Sun published under a license that made inclusion in the kernel impossible thus the current developers are bound by the same decisions regardless of their opinion on the matter. Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux be…

> Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking.

Let's say I make a movie M. It's a nice movie, but it doesn't have music. Someone else wrote some music S that is quite lovely. If anybody takes my movie M and mixes in music S, then the new movie is a derivative work of both M and S.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#99

Post by internalthief » Fri, Mar 20, 2020, 12:09 AM UTC

tialaramex wrote: post #97

internalthief wrote: post #94

Earlier quoted context omitted.

It seems that the server running on the other end doesn't properly match the certificate from the SNI if the domain sent by the browser is a FQDN (i.e. ends in a .) For example, try the following: openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk." vs openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk" You'll notice that in the first case the default certificate is sent back, in the second case t…

The relevant RFC says not to send a trailing dot in SNI. Browsers should probably trim the dot out if present. Maybe they aren't doing so because it causes some unexpected compatibility mishap, maybe in reality it rarely causes any trouble so nobody got around to it.

I was not aware of this!

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#100

Post by cyphar » Fri, Mar 20, 2020, 12:32 AM UTC

gnulinux wrote: post #51

tw04 wrote: post #25

Earlier quoted context omitted.

That's a great theory, but Linus picks and chooses when to decide it's outrageous to make changes that break userland tools based on his personal preferences. They intentionally broke ZFS - then Linus follows up with a wildly inaccurate statement about why he thinks nobody should use ZFS. It's difficult to take him seriously when he picks and chooses when to enforce his supposed "never break userland" ethos.

Did you read his mail though? He literally answers this criticism. ZFS is not userland so kernel developers are free to break it, just like they can break ext4 and do, and then they fix them. The problem with ZFS is that they can't fix it because it's not part of linux. It's a 3rd party kernel module. So your entire comment reads like a misunderstanding of the situation.

The breakage of ZoL wasn't a side-effect of some big technical change. They literally just made the SIMD enable/disable barriers no longer usable from non-GPL modules (the changed an EXPORT_SYMBOL to EXPORT_SYMBOL_GPL). This means you can't use SIMD-accelerated hashing functions from ZoL -- and there is no way to fix it without hurting performance other than reverting the "license change". And the entire justification for this change was "there are no in-kernel users".

Now, they are obviously free to do that and ZoL needs to work around it. But it's silly to argue that this was not an intentional breakage of a system which many people use and cannot be worked around out-of-kernel. Yes, it's not userspace code but it did cause regressions for users. Linus and GregKH have always disliked ZFS because they feel it was designed to be incompatible with Linux (and they're entitled to that view, however wrong it may be) so it's unsurprising that they are against doing anything that may help ZoL.