-
Notifications
You must be signed in to change notification settings - Fork 595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go.mod: move to latest secboot #13339
go.mod: move to latest secboot #13339
Conversation
|
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #13339 +/- ##
==========================================
- Coverage 78.96% 78.86% -0.10%
==========================================
Files 1028 1030 +2
Lines 129762 130548 +786
==========================================
+ Hits 102462 102958 +496
- Misses 20911 21177 +266
- Partials 6389 6413 +24
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
17764c1
to
73a3ca3
Compare
73a3ca3
to
9e4325c
Compare
9e4325c
to
ce639b4
Compare
|
fa2ae65
to
a984a37
Compare
dc5464a
to
8bc7657
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made a pass. An additional change that I wonder if is needed is that in the past parts of secboot were imported in snapd:
a466265
e45a076
and maybe we can use directly secboot now. But I don't know about the reason for importing code this way, maybe @pedronis has some context. Anyway, that should be possible a follow-up.
I had a quick look if I could build without it. It seems that we need this code to enroll recovery keys from snap-fde-keymgr. The functions it calls are in "internal" part of secboot and cannot be used directly. |
I have added the Block label, because we should not merge it yet. The new key format has to be merged together. But it should still be reviewed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes, I'm not approving yet as you mentioned that other things need to land first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, one question, did Chris have a look a the changes?
var handle []byte | ||
if keySetup.Handle == nil { | ||
// this will reach fde-reveal-key as null but should be ok | ||
handle = []byte("null") | ||
} else { | ||
handle = *keySetup.Handle | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why we don't need this bit of code/manipulation anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea. I believe that was done by Michael. I suppose we can revert this one if it breaks customers' fde-reveal-key
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose, if "fde-setup" does not set a handle. It probably does not care about the handle in the corresponding "fde-reveal-key".
I do not know if he looked through it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
6535984
to
734eaf7
Compare
734eaf7
to
7b339f9
Compare
7b339f9
to
bc9b81a
Compare
Everything is in #13951. Closing this one. |
No description provided.