> -----Original Message----- > From: Paul Moore (pmoore2) <pmoo...@cisco.com> > Sent: Wednesday, November 13, 2019 09:51 > 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 > > > I'm glad to hear that Python 3.x support is in the works, but I remain > concerned about the CLI support. While JSON/XML is better than nothing, it > still adds a bit of pain for those of us wishing to script the tools; while a > parameter based approach might not be pretty, it is much easier to script.
Agreed. CLI is a requirement. > I'm a bit farther down the patch of sorting out the policy patches for the > TXT/sig work, and as it currently stands it looks like the changes for > lcptools- > v2 is going to be very minor. Essentially it looks like the only changes I > will > need to make is to add a predefined custom ELT UUID for a certificate > payload, and even then that is optional (one can specify the UUID on the > command line if necessary). Are you adding the ELT UUID as a policy element plugin similar to mle_elt, sbios_elt, & stm_elt? > The other changes to the tboot policy would live > outside lcptools-v2 in tb_polgen. Would you be open to merging *small* > patches to lcptools-v2? > > I *really* don't want to have to deal with a GUI and/or JSON/XML if I don't > have to do so. > > On Wed, 2019-11-13 at 15:23 +0100, Lukasz Hawrylko wrote: > > 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
