linux-kernel - Re: [PATCH v4 02/12] kconfig: Add picosat.c (1/3)

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240829212352.38083-1-ole0811sch@gmail.com>
Date: Thu, 29 Aug 2024 23:23:52 +0200
From: Ole Schuerks <ole0811sch@...il.com>
To: mcgrof@...nel.org
Cc: deltaone@...ian.org,
	jan.sollmann@....de,
	jude.gyimah@....de,
	linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	masahiroy@...nel.org,
	ole0811sch@...il.com,
	thorsten.berger@....de
Subject: Re: [PATCH v4 02/12] kconfig: Add picosat.c (1/3)

On 8/20/24 00:04, Luis Chamberlain wrote:
> On Fri, Aug 16, 2024 at 12:20:01PM +0200, Ole Schuerks wrote:
>> What's the best way of letting the user know that they need to 
>> install PicoSAT if they want to use the conflict resolver?
>> My idea would 
>> be to notify the user via the GUI when they try to use the interface of 
>> the conflict resolver without having PicoSAT installed. Do you see any 
>> issues with that/do you prefer some alternative approach?
>
> Conflicts don't happen often and we already have a printf which happens when
> one does, my recommendation would be that we simply opt-in for the
> resolver if the user has the requirements installed. Otherwise we only
> inform the user to install it if a conflict comes up. Documentation can
> also be enhanced to describe this functionality / support.
>
>   Luis

There's perhaps a misunderstanding here. I think you are talking about the
rare scenario where a symbol is selected despite the dependencies not being
met (where the printf tells you that). But ConfigFix isn't only useful in
this case. We believe that the most common use will be to enable or disable
symbols with missing dependencies that prevent directly setting the
symbols' values via the GUI.

For example, when one symbol depends on a second symbol, and the second
symbol is set to N, then the first symbol cannot directly be set to M or Y
(assuming it isn't already selected by some symbol). One case of such a
constellation is DEBUG_MISC, which depends on DEBUG_KERNEL. ConfigFix can
identify that DEBUG_KERNEL must be set to Y in order to set DEBUG_MISC to
Y. Conflicts can also occur when trying to lower the value of a symbol: If
a symbol is selected by a second symbol, and the second symbol is set to Y,
then the first symbol can't directly be set to N or M. One such case is
EXPERT, which selects DEBUG_KERNEL.

So, the conflict resolution is useful when users want to quickly enable
some grayed out symbols. If one has to install some external package first,
then that might diminish the usefulness. While there are extreme cases
where it can take hours to manually identify all the dependencies, first
having to build PicoSAT might take longer than manually resolving the
conflict. Many users might then never install PicoSAT to try out the
conflict resolver, even if they would benefit from it.

So the question is whether using PicoSAT as an external library is worth
the portability issues and effort, and whether it wouldn't make more sense
to directly include the PicoSAT source file.

Otherwise, if we go with not including the PicoSAT source, then one could
inform users about the missing package in the GUI, like this:
When PicoSAT is installed:
https://drive.google.com/file/d/1asBfLp1qfOq94a69ZLz2bf3VsUv4IYwL/view?usp=sharing
When PicoSAT is not installed:
https://drive.google.com/file/d/1ytUppyFPtH_G8Gr22X0JAf5wIne-FiJD/view?usp=sharing

Let us know what you think. Include PicoSAT directly as a source or not,
and then inform the user via the GUI?