Hi,
thanks for the feedback. I am totally on your site that this is not an ideal solution - however the coreboot community has to think about how to work around these issues. Stating that this just does not get merged into the tree is not a good solution, as we are not moving forward on these topics and can not compete with proprietary solutions if we are holding on to the statement that also tooling needs to be open-source.
Don't get me wrong - I love open-source and don't understand why these things, especially when they are security critical, are closed-source. That is against what I learned from as a security researcher - and this is what security does for years now - open-sourcing the concepts, algorithms and so on.
So - I am always a fan on moving forward, and also moving fast forward. However: we cleared out the NDA issues and released the tool into the public [1]. That being said - NDA issues are off the table now.
---
Golang did quite some work on the dependency system and I know it tends to be confusing. But things get better - plus python is not any better on that. But don't get me started on that ;)
Best,
Chris
[1]: https://github.com/9elements/converged-security-suite/
On 2/23/21 12:26 PM, Enrico Weigelt, metux IT consult wrote:
On 09.02.21 13:14, Christian Walter wrote:
Hi,
As Arthur pointed out, we would hope to integrate this as a binary as a temporary solution, until Intel clears out the NDA issues.
I really don't like this idea. As it's a special case for the time being, this can live in some extra branch, possibly extra repo, just for those few folks who really need it right now.
Adding binary cruft to the mainline removed the pressure for folks like Intel (which is an exceptionally ugly player in this regard) to clear up everyhing. They should feel the presure of being ignored (at best), until they provide a really clean solution. They should learn once for all that those things never should have been under NDA in the first place.
Note: this has nothing to do with (dis)repsect regarding your work.
And also in the sense of moving forward, I would like to choose Golang over C in this case.
hmm, golang in general is a bit problematic in distro context. (anyone, who tried clean packaging and build process of golang and go applications for distros like Debian, knows what I'm talking about :p) ... it's a nice language, but getting their own ecosystem isle (damn, they even built their own wannabe package manager) play along nicely with distros is a pretty huge and non-trival job.
Personally, for that kind of job, I'd prefer something like Python :p
--mtx