Closed ghost closed 1 year ago
I think one could play around the user namespace feature to make private key only visible in container, but i'm not sure. Also it's pretty much a prototype so you probably shouldn't merge it directly. That said I've used this to generate rpm and it worked well.
almost forgot: you need to first toolbox create -y
, otherwise toolbox run
fails
That's an awesome work!
The only directory touched by this script is the current directory
That's really good!
No more hardcoding /root
Yes, but isn't there a hardcoding for UID 1000? (see my coments above)?
Also gets rid of having to layer rpmdevtools on host
That's also something that made me unhappy.
I had once the idea to use podman for building this project. This could also achieve these goals. I was unfortunately too lazy to do this.
My main concern with your approach is that the user gets access to the akmod keys. I'm not sure that this is something that I want. A minor isse is IMO that it somehow pollutes the toolbox environment (could be easily solved by using a separate toobox or use podman).
hardcoding for UID 1000
yeah, i left it there as some building tools refuses to run when uid is 0 (root). should be safe as long as any non-zero uid is used. bwrap inherits host uid. when bwrap runs as normal user --uid
and --gid
can be removed.
the user gets access to the akmod keys
it's my main concern as well, an arbitrary user program gets to read that very secret private key. but then i don't want to do too may things as root because that is also dangerous.
maybe i'll check the podman approach (but then my laziness is the gatekeeper). PR is here anyway so if you want to adapt something you can always copy-paste it.
/root
rpmdevtools
on hostI say do not merge as you should check if it's something you want.
Fixes https://github.com/CheariX/silverblue-akmods-keys/issues/5