Some more lanzatool refactoring #43
No reviewers
Labels
No labels
bug
dependency
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
review-next
security
stub
tool
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
raito/lanzaboote!43
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "some-more-lanzatool-refactoring"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implements some requested changes from #34.
@nikstur Do you think we could get the "alternative Nix store" path feature and make it a parameter or something smart?
IMHO, a UEFI String is a UTF-16 string, but String is a UTF-8 String AFAIK.
This function is more a "UNIX paths to Windows-style paths" AFAIK
I wonder if
windows::Path
could be directly imported.From some research, I got the impression, that an alternative Nix Store path is not really a well-supported feature of Nix e.g. https://github.com/NixOS/nix/issues/1971. I'd say we just do not explicitly support an alternative path. With the implementation from #42 lanzatool doesn't really know about /nix/store at all anyways, so other store locations should just work. I implemented it that way so I can test with files in a temporary directory instead of /nix/store. (See: https://github.com/nix-community/lanzaboote/blob/master/rust/lanzatool/src/esp.rs#L56)
From what I can tell you can't easily convert a path using the stdlib. I found this library: https://github.com/r-efi/r-efi-string.
From the readme it seems that UEFI strings are even more complicated than just UTF-16. Do you think the comment or function name is not fitting? I'm not sure we gain much if we encode the complexities of UEFI Strings into e.g. the function name.
It definitely is, the issue you linked is about rewriting the paths which is something different and could be useful to reuse the NixOS cache in an alternative store path.
But, if you do
nix-build x --store ~/nix
, it will create a new Nix store at this path.Some people do run Nix store paths at alternative locations, certainly, this is very edgy, but I'm not sure if it cost that much to support it as a flag.
Hm, that's fair. We can wait for a feature request then.
Great!
In that case, I'd just add a warning that it's not exactly a UEFI-spec compliant function, and it's fine IMHO.
Love the unit tests!