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.
[1]: https://github.com/9elements/converged-security-suite/
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
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
