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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20240920090712.52825-1-ole0811sch@gmail.com>
Date: Fri, 20 Sep 2024 11:07:12 +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 9/5/24 10:55, Luis Chamberlain wrote:
> On Thu, Aug 29, 2024 at 11:23:52PM +0200, Ole Schuerks wrote:
>> 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.
>
> That's a package dependency problem, ie, a distro thing to consider
> which packages users should have installed. But isn't the bigger issue
> the fact that you want some C library not the picosat binary tool? Or
> would it suffice to just have picosat as a binary installed? I see at
> least debian has python3 bindings now too python3-pycosat. So what type
> of picosat integration really is best for the task at hand?
>
>> 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.
>
> The pros of an external library are less burden on maintenance, and
> otherwise we'd be forking PicoSAT, but as I mentioned, I don't see a c
> library but instead just the picosat binary. An alternative is to use PicoSAT as
> a git subtree inside Linux on a dedicated directory, this way PicoSAT
> can evolve and we can update it when we need to. Note a git subtree is
> not the same thing as a git submodule, those are terrible.
>
>> 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?
>
> Do you need the picosat binary or the actual c code for helpers /
> library?  I don't think we have anything in Linux yet using git
> subtrees, but I don't see why we wouldn't for generic tooling and
> this might be a good example use case.
>
>   Luis

The packages mentioned in
https://lore.kernel.org/all/20240710065255.10338-1-ole0811sch@gmail.com/T/#m34fdf309ecd545d72d898655d8c1a2653d1cdb81
include the necessary libraries. The Python bindings aren't useful for our
purposes, unfortunately, since many important features are missing, in
particular the tracing of which assumptions failed. Using PicoSAT as a
library seems to be the best solution.