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

Message-ID: <ZtlyCR4EloWbeWG7@bombadil.infradead.org>
Date: Thu, 5 Sep 2024 01:55:37 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Ole Schuerks <ole0811sch@...il.com>
Cc: deltaone@...ian.org, jan.sollmann@....de, jude.gyimah@....de,
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
	masahiroy@...nel.org, thorsten.berger@....de
Subject: Re: [PATCH v4 02/12] kconfig: Add picosat.c (1/3)

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