Thank you for feedback, I understand your point. I was talking with tools maintainer and he started working on migration to Python 3.x and better CLI support (together with documentation how to use it). Our idea is not to add enormous list parameters to generate LCP with desired options, but to add JSON/XML file that will describe LCP in human- readable format. After preparing that file (you can do that in VIM) you will feed it into tool and than get LCP. I would like to hear your opinion about that idea.
The only reason why I don't want to maintain lcptools-v2 is to not have two tools that do the same thing. I hope that with your input we can improve lcp-gen2 so it can replace lcptools-v2 in every case. In my opinion adding CLI to GUI application is easier than adding GUI to CLI application, that's why I decided to go with lcp-gen2. We are working on lcp-gen2 in our local repository, I will ask maintainer when he will be ready with Python 3.x migration if that will be less than month I will wait for that to release new version. Lukasz On Fri, 2019-11-08 at 18:34 +0000, travis.gilb...@dell.com wrote: > > -----Original Message----- > > From: Paul Moore (pmoore2) < > > pmoo...@cisco.com > > > > > Sent: Friday, November 8, 2019 11:19 > > To: > > lukasz.hawry...@linux.intel.com > > ; Gilbert, Travis > > Cc: > > tboot-devel@lists.sourceforge.net > > > > Subject: Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern > > system with TXT+TPM2 > > > > On Fri, 2019-11-08 at 12:47 +0100, Lukasz Hawrylko wrote: > > > For TPM2.0 LCP generation there is a Python tool lcp-gen2 that is > > > included in tboot's source code. To be honest I didn't try to generate > > > LCP with tboot's VLP inside but it should work. If not - this is a bug > > > and need to be fixed. > > > > > > lcptools-v2 will is not maintained, any new features like new signing > > > algorithms will not be included there, so I suggest not to use it for > > > new designs. We are actively improving lcp-gen2, if there is something > > > that is missing in your opinion please let me know. > > > > A few problems come to mind with lcp-gen2 all of which are blockers: > > > > * I see references to upgrading to newer versions of Python 2.x, but nothing > > about upgrading to Python 3.x; with Python 2.x going EOL in a few months > > this needs to happen very soon. > > > > * No documentation. This is a general problem with the tboot > > code/tools: there is very little documentation, and what does seem to be > > present is mostly wrong or incomplete. > > > > * The lcp-gen2 tool appears to be intended mostly as a GUI tool, and I need > > a > > CLI tool. It looks like there might be some sort of "batch build" > > available from > > the command line, but I don't see any further explanation or documentation > > on this ability. > > > > You mention that lcp-gen2 is being actively improved, is this happening > > offline? The last commit I see is to the sf.net repo for lcp-gen2 is over > > six > > months old. > > > > If these issues can't be resolved within the next month or two, is there any > > reason why we couldn't continue to make changes to the lcptools-v2 tools? > > > > -Paul > > > > I'm with Paul. I strongly disagree with discontinuing support for lcptools-v2. > > lcp-gen2 requires that you have a Window Manager installed. It requires > clicking around in a GUI. Both of these limit its use. The most important > thing it limits is the ability to script LCP creation like I have done. When > I give someone else an LCP to use, instead of a 10 page document with > pictures that walks them through clicking everything in lcp-gen2, with > lcptools-v2, I can just say "Run this script." If that script doesn't error > out, then I *know* that the LCP was correctly created. In the lcp-gen2 case, > I have to have the user send me the LCP and other intermediate files and > compare them with what I expect in order to figure out whether something went > wrong or not. Troubleshooting for a script is simpler. If for some reason > they can't copy & paste the console output with the error (very easy), I can > have the user run the script again while redirecting the output to a file, > and then send me the file. > > I also have philosophical issues with GUI-only, mostly that it violates the > UNIX philosophy of "Write programs to handle text streams, because that is a > universal interface." My evidence for why this should be considered consists > of my previous paragraph and Paul's concerns. > _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
