On 23.02.21 12:35, Christian Walter wrote:
Hi,
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.
how did competition become a criterium for coreboot ?
I can only speak for myself here: my interest in coreboot is nothing more than having a properly working solution (which, of course, includes maintainability on a very high position on the requirements list) for certain boards, that I'm interested in. And, if possible, punch some ugly corps like Intel in the face, as a nice collateral benefit. Anything else is out of my scope - I've given up trying to heal the world.
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.
Good, but you should also know that all of that only really works, if done consequently. For Intel SoC, eg. it means: as long ME remains closed, the platform remains inherently insecure, because you've got non-trustworthy folks having control over the most critical part.
So - I am always a fan on moving forward, and also moving fast forward.
I prefer, not just forward, but in the right direction for my goals. And not fast, but well though, clean and consequent steps.
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.
Great. So, what's still left to do here ?
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 ;)
Okay, it's been a while since I touched golang. Having to upgrade the compiler, just to get some arbitrary program running, which leads to repackage a long list of compiler versions built in sequential order, since I neither use some bleeding-edge-distro, nor any precompiled binaries (except those from official distro repo, or built myself), doesn't exactly sound inviting.
Python had similar problems, but (at least for the vast majority of packages) it's under pretty good control. I've already scripted up an (almost) fully automatic import and debian packaging that's capable of packaging large portion of pypi.org, with minimal set of manual intervention (yes, there still are ugly exceptions). Of course, we could do something similar w/ go, but defeating the horribly mishabit of "vendoring" (useless manual code duplication) isn't so trivial.
Just having a quick look at the code ...
#1: I hope you're aware of that things like "goreleaser", that completely bypass the distro infrastructure and call lowlevel tools directly, are exactly an example for the already mentioned distro hostility (BTW: ruby folks, which are even worse, already stated openly, how they hate distros and wished to get rid of them), that makes me very reluctant of getting anywhere near golang.
#2: if you wanna attract people actually using it, you should perhaps tell clearly how to build it and provide a nice Makefile. (dont expect everybody to keep in mind how the 10.001th build system works :p)
#3: about half an hour of external downloads from arbitrary sources, before actual build even starts, isn't actually inviting. IIRC, our discussion was about some tool for just signing an image.
#4: several coffees later, 'go build' breaks:
can't load package: package github.com/9elements/converged-security-suite/v2: unknown import path "github.com/9elements/converged-security-suite/v2": cannot find module providing package github.com/9elements/converged-security-suite/v2
#5: autogenerated stuff should not go into a source repo
#6: trying to run the fist step in the circleci script gives:
go: downloading github.com/fatih/camelcase v1.0.0 go: downloading github.com/xaionaro-go/gosrc v0.0.0-20201124181305-3fdf8476a735 go: downloading github.com/fatih/structtag v1.2.0 go: downloading github.com/xaionaro-go/unsafetools v0.0.0-20200202162159-021b112c4d30 # github.com/xaionaro-go/gosrc ../../../go/pkg/mod/github.com/xaionaro-go/gosrc@v0.0.0-20201124181305-3fdf8476a735/directory.go:106:19: undefined: os.UserHomeDir ../../../go/pkg/mod/github.com/xaionaro-go/gosrc@v0.0.0-20201124181305-3fdf8476a735/directory.go:149:33: undefined: importer.ForCompiler
At that point, I've given up. Not usable for production :(
[ BTW: did you see that golang.org openly supports an Soros-financed violent terror organisation, that already devastated several major cities in the US last year and also stormed into the US capitol ? I really don't like to have anything to do with those people. ]
--mtx