lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87a7lct9j0.fsf@dell.be.48ers.dk>
Date:   Tue, 11 Dec 2018 15:36:51 +0100
From:   Peter Korsgaard <peter@...sgaard.com>
To:     Jean Delvare <jdelvare@...e.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "firmware: dmi_scan: Use lowercase letters for UUID"

>>>>> "Jean" == Jean Delvare <jdelvare@...e.com> writes:

 > On Tue, 2018-12-11 at 13:06 +0100, Peter Korsgaard wrote:
 >> > > > > > "Peter" == Peter Korsgaard <peter@...sgaard.com> writes:
 >> 
 >> Hi Jean,
 >> 
 >> >> Look, you can imagine that I was perfectly aware of what I was doing
 >> >> when I made that change, and that I pondered the decision carefully at
 >> >> that time. And my decision was that the change should be made. As far
 >> >> as I'm concerned, this ship has sailed already, sorry.
 >> 
 >> > Sorry, what is the perceived risk of reverting this change? Just the
 >> > minor inconsistency between the dmidecode and sysfs output? As stated
 >> > above, the RFC requires conforming parsers to handle upper case as well.
 >> 
 >> I would appreciate if you could explain what risk you see from reverting
 >> this change?

 > The exact same risk that you are complaining about, for a different
 > pair of kernel versions. You cannot at the same time argue that the
 > change should not have been done back then, and ask for same change to
 > be done again now.

With that kind of catch-22 logic, no regressions can ever be fixed. This
change was part of 4.17, released 6 months ago, whereas the previous
behaviour has existed for an order of magnitude longer.

While it is true that there is a chance that somebody may rely on the
new behaviour, it is likely to be significantly smaller than the chance
that someone relied on the previous behaviour (E.G. the breakage in my
software is proof of at least one such instance). Given that 4.19 has
only recently become a LTS kernel and distibutions with 4.17+ are only
getting released now (Fedora 29, Ubuntu 18.10) chances are that more
people will be affected in the future.

But you are right, we should do the revert as soon as possible, before
people start relying on this new behaviour.

I can extend the commit message with a reference to RFC4122 if you
prefer that over my "the change was purely cosmetical" wording?

-- 
Bye, Peter Korsgaard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ