Import paths in burmilla/trash is not updated, still pointing to rancher/trash

[h8liu]

In the main Dockerfile.dapper (the ubuntu one), it builds and installs burmilla/trash using go get github.com/burmilla/trash. However, import paths in the burmilla/trash repository still points to rancher/trash. As a result, the trash binary will be compiled from both code from burmilla/trash and rancher/trash. If code rancher/trash changes, the build process might break.

This is at least an inconsistency. Do we treat rancher/trash as our official upstream? Or we want to go full branch off and use everything from github.com/burmilla (we can still optionally keep tracking updates on rancher, but we need to update all import path).

Other go-gettable build tools (such as the dapper forked repo) have similar issues.

Another higher level thing is that the build process currently fetches a lot of stuff from the Internet, mostly without checking against any hashes. IMHO, this is a huge reliability -- and even security -- issue. Although most channels and fetching-sources can be considered trustworthy, many of them are quite mutable (and it is not unheard of that attackers might be able to poison trusted software distribution channels).

Failure example: burmilla/os-kernel@6a6748a
(and rancher is still ignoring my pr: rancher/dapper#93 ; I suspect the project is dying..)

So folks, a high level question: is it a desirable goal to build as much as possible from source (with a fixed set of toolchain docker images) without Internet access?

[olljanat]

In the main Dockerfile.dapper (the ubuntu one), it builds and installs burmilla/trash using go get github.com/burmilla/trash. However, import paths in the burmilla/trash repository still points to rancher/trash. As a result, the trash binary will be compiled from both code from burmilla/trash and rancher/trash. If code rancher/trash changes, the build process might break.

This is at least an inconsistency. Do we treat rancher/trash as our official upstream? Or we want to go full branch off and use everything from github.com/burmilla (we can still optionally keep tracking updates on rancher, but we need to update all import path).

We want to be able to BurmillaOS without unexpected changes even if Rancher removes/changes their repos so any references to "rancher" to repos should be considered as bug which should be fixed.

I did notice that hardest part on forking RancherOS was actually name change because I wanted to keep backward compatibility (which why user name is still "rancher" and cloud init configs uses configuration items under "rancher" name) but still fork all needed code under burmilla repositories.

Also it is worth to mention that because of timing I did use some shortcuts like just copying os-base and os-system-docker release binaries from rancher repos to our repos.

Other go-gettable build tools (such as the dapper forked repo) have similar issues.

Another higher level thing is that the build process currently fetches a lot of stuff from the Internet, mostly without checking against any hashes. IMHO, this is a huge reliability -- and even security -- issue. Although most channels and fetching-sources can be considered trustworthy, many of them are quite mutable (and it is not unheard of that attackers might be able to poison trusted software distribution channels).

Failure example: burmilla/os-kernel@6a6748a

Dapper is one of those areas where I used shortcut and leaved references to rancher repos as Rancher Labs uses it on all their repos and I expected that they will maintain it nice way (but did fork it repo under burmilla still just in case) but I see it now that doing that without version locking was at least bad idea which I was forced to fix last time to be able to create v1.9.1 release.

(and rancher is still ignoring my pr: rancher/dapper#93 ; I suspect the project is dying..)

I don't think that it is dying but after SUSE acquired Rancher Labs they are most probably just forced to focus other things than feedback which comes from community.

So folks, a high level question: is it a desirable goal to build as much as possible from source (with a fixed set of toolchain docker images) without Internet access?

IMO, goal should be that anyone who download all burmilla repositories should be able to build BurmillaOS without internet access. What comes to official releases my goal have actually totally opposite where all those build are using GitHub actions and running their servers on way that all the build logs are public so anyone is able to see that how example our v1.9.1 release is really built.

[olljanat]

So folks, a high level question: is it a desirable goal to build as much as possible from source (with a fixed set of toolchain docker images) without Internet access?

IMO, goal should be that anyone who download all burmilla repositories should be able to build BurmillaOS without internet access.

Btw. I just noticed that this one is in conflict with my proposals to use signed kernel binaries from Ubuntu releases #5 (comment) #8 (comment) so we most probably need to decide that:
a) Do we want build everything from source?
b) Do we want support secure boot with UEFI?
because I think that we are not able to kernels which we build our selves.

[h8liu]

UEFI does not have to enable secure boot. At least for us, support booting (and updating) on UEFI boards is first priority. Supporting secure boot is kind of optional, and many systems support swapping the signing key.

I am not super familiar with GitHub actions. Do they support building without Internet access?

My opinions:
a) We should build as much as possible from source. For imported/downloaded stuff, we should always lock them with hashes.
b) We should try to support UEFI booting first (with secure boot disabled)
c) We can then try to solve the signing problem, not only figuring out the signing itself is not easy, but standing up the signing infrastructure for releases is also non-trivial.

[olljanat]

I am not super familiar with GitHub actions. Do they support building without Internet access?

No. Whole idea with those is automate build process and outsource build servers maintenance process for GitHub. However build process contains just need to run couple of commands https://github.com/burmilla/os/blob/master/.github/workflows/create-release.yml so it is quite simple to run those also manually.

For imported/downloaded stuff, we should always lock them with hashes.

Yes. Most of the external code is already vendored to burmilla repos with commit hashes so it shouldn't big task.

Anyway, closing this as trash references was fixed on burmilla/trash@6b5123d