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 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
