this removed the need to check it in xbmk_set_version
as it calls update_xbmkver, which in turn performs
the same check.
this increases the general reliability and safety of
xbmk when recording its own version after update.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we don't pull anything from supermicro's site.
we did briefly, in an earlier port for that
one supermicro board.
don't maintain dead code. dead code has one purpose:
be deleted.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i will be adding chromebooks, but not using this script,
which is why i never finished the script. i previously
had the plan to patch upstream coreboot, by importing
patches from mrchromebox, but that results in an extreme
number of patches. several hundred patches, in fact.
more efficient is to add multi-upstream support in
include/get.sh, for using different upstreams including
forks, on a given multi-tree project. i haven't done
this yet, but this is what will be done, and then
adding each chromebook will be a matter of importing
configs from mrchromebox alongside edk2 integration.
a script will still need to be written, for the initial
import, and imported chromebooks will be set release=n
until and when each target is fully tested.
Signed-off-by: Leah Rowe <leah@libreboot.org>
infinite loop detection was here before. i removed it
because it was bloat. we don't take general user input
here, so careful configuration is all we need.
infinite loops are harmless to the user. they are merely
annoying. they would never be introduced to the user,
because configs are always tested before release.
before commit, even.
we can save the user a few watts of electricity, or we
can Keep It Simple.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this one is unnecessary, because we're not taking general input
from the user. we mitigate this carefully by being, you know,
careful.
implementing the TODO would have bloated the code, in ways that
might only introduce other serious bugs.
the current logic is fine, and great care will always be taken
by me to keep the code safe, while i'm in charge.
Signed-off-by: Leah Rowe <leah@libreboot.org>
only the author date was being set before
with this change, at least on my system, i
now get the same commit ID and date each time
on the following test:
NOTE: . is lbmk (main work directory)
NOTE: here, we are copying the current clone
git clone . lbmktest
cd lbmktest
./mk version
rm -Rf .git
./mk version
git log
same output each time. we have thus eliminated
timestamps as a variable. this is but a part of
in a series of changes that will eventually lead
to libreboot being built reproducibly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
don't even call the date util at all, to fix the
portability issues. now we don't need GNU date
anymore.
git itself can just take an epoch, and it will
do whatever it will do. yes.
Signed-off-by: Leah Rowe <leah@libreboot.org>
even if i unset PATH before running lbmk, it is
reinitialised because of the shebang. if no PATH
exists, then it's either a broken system and you
have bigger problems, or you have some weird
system that uses something else.
our job is not to fix the world. there was no
scenario in which this check would even trigger
an error or fallback, so just remove it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i've been careful to makely only use it on AND operations,
not onse that use OR. a lot of blocks are not condensed,
unlike previously when this design was used.
i removed the condensed design because it made the code
allegedly easier to read, but i found it harder to read
and found the code looked dirty. this change makes it
clean again, but i've done it in a way where the shorthand
conditional statements are easy to understand for most
people. this strikes a compromise; i would go further.
Signed-off-by: Leah Rowe <leah@libreboot.org>
use the simpler logic recently introduced, generalised
but it only sets variables to empty. this is safer than
the previous design, and brings the same reduction in
sloccount overall since i wasn't doing anything other
than emptying variables anyway, when it was used before.
i didn't like the long list of variables inside files,
so this makes everything more readable.
Signed-off-by: Leah Rowe <leah@libreboot.org>
commands now fed from a file, include/common.sh
which in turn also includes other lib files
this makes mk completely generic, and means
that changes will now be completely in sync
with cbmk, ensuring a lack of merge conflicts,
though the file was already pretty small anyway.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i made several modificatinos to several files
thus for in 2026, in the main part of the build system.
i've added 2026 to the ones that i modified.
Signed-off-by: Leah Rowe <leah@libreboot.org>
with this new function, i can turn commands on and
off by virtue of config. for now, behaviour is
unchanged, but this new design means i will be
able to disable certain commands in child processes
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit 1b65e8914c.
NOTE: cleanup of xbmk_git_init was retained
this "cleanup" actually made the code harder to read.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this will make managing updates easier. which will
be soon, because i have a lot of patches.
no idea why i didn't add this before. normally, i just
copy a directory and git-fetch, then cherry-pick as
i please. this will make it trivial to just update
a revision and merge the patches. then i can just
intervene only when necessary, on a given src tree.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the previous patch was half the battle. now that
annoying person who complained on irc should be
happy.
someone complained about having to enter git
name/email when just doing e.g. ./mk inject
a valid complaint, but their attitude kinda
stunk. oh well. this patch should satisfy them.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Some users have it in a file e.g. inside ~/.gitconfig
Those users are currently forced to set git config
globally by lbmk. We only need to check that a git
config is set, regardless of scope, because coreboot
needs it in parts of its build system when used on
lbmk.
This prevents a pointless error report for users who
have their git config on such a scope. Thanks go to
Hendrik Jäger for reporting this to me.
Yes, thank you. Further context:
https://lore.kernel.org/git/20260720113402.0dc16abe@frustcomp.hnjs.home.arpa/T/#u
Signed-off-by: Leah Rowe <leah@libreboot.org>
i'm trying to make nvmutil work on openbsd. the new code
in lbutils is a bit buggy, likely somewhere in mkhtemp.
i'm still debugging it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i added a fake -t option, which doesn't actually
read optarg, so that -t usage can just override
the normal template. mkhtemp isn't ready for
distros yet, but it's ready for lbmk.
i hacked the makefile to also copy the binary to
mktemp, and i set PATH in lbmk so that this binary
is used insttead of the one on your system.
that way, upstream projects use it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This will also be used in lbmk itself at some point,
which currently just uses regular mktemp, for tmpdir
handling during the build process.
Renamed util/nvmutil to util/libreboot-utils, which
now contains two tools. The new tool, mkhtemp, is a
hardened implementation of mktemp, which nvmutil
also uses now. Still experimental, but good enough
for nvmutil.
Mkhtemp attempts to provide TOCTOU resistance on
Linux, by using modern features in Linux such as
Openat2 (syscall) with O_EXCL and O_TMPFILE,
and many various security checks e.g.
inode/dev during creation. Checks are done constantly,
to try to detect race conditions. The code is very
strict about things like sticky bits in world writeable
directories, also ownership (it can be made to bar even
root access on files and directories it doesn't own).
It's a security-first implementation of mktemp, likely
even more secure than the OpenBSD mkstemp, but more
auditing and testing is needed - more features are
also planned, including a compatibility mode to make
it also work like traditional mktemp/mkstemp. The
intention, once this becomes stable, is that it will
become a modern drop-in replacement for mkstemp on
Linux and BSD systems.
Some legacy code has been removed, and in general
cleaned up. I wrote mkhtemp for nvmutil, as part of
its atomic write behaviour, but mktemp was the last
remaining liability, so I rewrote that too!
Docs/manpage/website will be made for mkhtemp once
the code is mature.
Other changes have also been made. This is from another
experimental branch of Libreboot, that I'm pushing
early. For example, nvmutil's state machine has been
tidied up, moving more logic back into main.
Mktemp is historically prone to race conditions,
e.g. symlink attacks, directory replacement, remounting
during operation, all sorts of things. Mkhtemp has
been written to solve, or otherwise mitigate, that
problem. Mkhtemp is currently experimental and will
require a major cleanup at some point, but it
already works well enough, and you can in fact use
it; at this time, the -d, -p and -q flags are
supported, and you can add a custom template at
the end, e.g.
mkhtemp -p test -d
Eventually, I will make this have complete parity
with the GNU and BSD implementations, so that it is
fully useable on existing setups, while optionally
providing the hardening as well.
A lot of code has also been tidied up. I didn't
track the changes I made with this one, because
it was a major re-write of nvmutil; it is now
libreboot-utils, and I will continue to write
more programs in here over time. It's basically
now a bunch of hardened wrappers around various
libc functions, e.g. there is also a secure I/O
wrapper for read/write.
There is a custom randomisation function, rlong,
which simply uses arc4random or getrandom, on
BSD and Linux respectively. Efforts are made to
make it as reliable as possible, to the extent
that it never returns with failure; in the unlikely
event that it fails, it aborts. It also sleeps
between failure, to mitigate certain DoS attacks.
You can just go in util/libreboot-utils and
type make, then you will have the nvmutil and
mkhtemp binaries, which you can just use. It
all works. Everything was massively rewritten.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe
Zoomm Deka
Leah Rowe
Baraa Al-Masri