-
Notifications
You must be signed in to change notification settings - Fork 131
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
ITRenew SHIM 15.7 amd64 and i386 #323
Comments
Our issue has been tagged with the 'incomplete' label. |
At the time that tag was applied, you had not filled out the issue template completely. |
Please advise on next steps in this process. Do the verification emails need to occur before the review is started? |
Is there any update on the status of our request? Are we missing any information for this review to proceed? |
|
Thank you Dennis. |
Is there anything we can/'need to' do from our side to move this process along? |
The review is done very well and it surprised me positively how you implemented NX support - using the native functionality rather than porting a patch. Although there's one error I noticed. Take a look:
There are some NUL characters, which shouldn't be here. You'll need to port this patch and once that's done, update the shims' checksums. Also, I interpret the question
Regarding the update status of your request I heard somewhere the official reviewers are already overworked with their jobs unrelated to reviewing. And Robbie said this too:
I think we all may review other reviews to make it easier for the official reviewers. I pointed out something in yours, you may review the one I posted as a token of appreciation. ;) |
@aronowski |
@aronowski We have applied this patch and rebuilt EFI binaries. Currently .sbat and .sbatlevel sections look like:
Checking for NX Support:
Confirmation of checksums:
And compare them with checksums from the Dockerfile's build.log:
Checking if a code section is read-only:
Unfortunately, I could not find information on how to initiate the process of Contacts Verification specified in the template. Thank you. |
I can see the updates. Reproduced the artifacts as well and everything looks good to me. Great job! Regarding the verification of contacts, I believe only the ones by authorized reviewers count. The same when it comes to labeling issues and, as far as I understand, letting Microsoft know on the updates. I can perform this process unofficially for you to make you happy but I don't think it will count. I believe the best we can do is to, as mentioned in my previous comment, help with the peer review so the official reviewers have less work to do manually - especially if there are some hard-to-notice errors, which can be fixed in the meantime. For instance I can see you reviewed the review I initiated and I'm grateful for that. That's a way of learning, how all this works. You can review other reviews too, confirm that others' builds are reproducible, look for common errors, etc. even if they already have been reviewed by someone else, like this one. I hope this goes well and wish you all the best! |
Is there any way to expedite this process? |
Review of
|
Hi Thore, Thank you for your review.
ITRenew was acquired by IronMountain. We were in the process of purchasing the certificate and it was decided to continue with the ITRenew name at that time. Our ITRenew emails will route to our IronMountain inboxes. Hope that helps. Please revert back if you have additional questions on this. |
Hi Thore, Thank you very much for the review.
New hashes:
I also updated the README.md template with these new hashes the have created a new tag: Unfortunately I don't have permission to edit this issue to reflect hashes and tag changes in it as well.
No, we do not use ephemeral key for signing modules for our current kernel.
In the next iteration we plan update the kernel in our platform to the next longterm support kernel 6.1.x. And we definitely will use ephemeral key module signing for it. Thanks. |
SBAT entries are now fixed and shims also reproducible:
According the the kernel documentation changing the local version every time is a valid strategy (https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html#administering-protecting-the-private-key). I'll remove the bug label, once the top issue comment is updated to the new information. |
@THS-on |
While trying to sending out the contact verification messages, I noticed that the PGP key for David Friedman only includes the email address dfriedman@ironmountain.com not david.friedman@ironmountain.com (https://keyserver.ubuntu.com/pks/lookup?search=B2C6438FFDE5A3AAFB8CE3BEA3CD579F25D41BC3&fingerprint=on&op=index). Can you update that? |
@THS-on Thank you for reviewing! |
The following words were received by Keith: sauce |
The following words were received by David midterms |
Contact verification is complete the phrases are correct. I would like that another reviewer again take a look at it, because it is a new vendor. @dennis-tseng99 @aronowski can one of you take another look at it? Note that we are currently discussing what are the acceptable strategies for kernel module singing, besides ephemeral key singing. So we are likely only marking the submission as accepted once we agreed on that and it matches your approach. |
@THS-on, I'll perform an additional review soon, most likely the next Monday. Assigning this one to myself. If there are no major errors, I'm then marking this application as accepted, since the people behind it do have broad knowledge on the subject. |
I've checked the changes and the build reproducibility. Everything looks alright.
On April 24 I wrote:
And it did! We can celebrate! ;-) |
Kamil, Thore, Dennis and everyone, |
Yes, thank you to all for your time on this matter. It is greatly appreciated. |
Hello colleagues, Two months ago, when we were preparing Cabinet file with included shim images to submit an application to Microsoft, we had a hardware failure with the eToken FIPS device where our company's EV Code Sign certificate is stored. It stopped working and we were unable to sign the Cabinet file. It took some time for the certificate authority to help us and the issuer confirmed that it is not possible to restore the eToken FIPS and the certificate on it is lost, so we need to issue a new certificate. We received a replacement of a new hardware eToken FIPS with a new certificate issued. I updated this shim-review request with a new issued vendor certificate for approval. Change list:
@keithdlopresto Could you please edit this issue and update two hashes and tag link?
https://github.com/ITRenew/shim-review/tree/ITRenew-shim-amd64_i386-20240118 Thank you! |
Issue details updated with new Tag link and Hash values with Vlad's latest update. |
The build reproduces, checksums match, NX support properly disabled until the whole chain gets NX support. Certificate is valid. Great job! Leaving the accepted label as it was. ;-) |
Thank you very much for your help and review! We'll start preparing for the Microsoft submission. Thanks. |
Thank you for the quick response and re-review.
Very much appreciated!
…On Fri, Jan 19, 2024 at 2:49 AM aronowski ***@***.***> wrote:
The build reproduces, checksums match, NX support properly disabled until
the whole chain gets NX support. Certificate is valid.
Great job! Leaving the *accepted* label as it was. ;-)
—
Reply to this email directly, view it on GitHub
<#323 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A5SABVJJ5K2ZKFFMGMH27TTYPJFUXAVCNFSM6AAAAAAVMMSE2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBQGE3TONJUHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
The information contained in this email message and its attachments is
intended only for the private and confidential use of the recipient(s)
named above, unless the sender expressly agrees otherwise. Transmission of
email over the Internet is not a secure communications medium. If you are
requesting or have requested the transmittal of personal data, as defined
in applicable privacy laws by means of email or in an attachment to email,
you must select a more secure alternate means of transmittal that supports
your obligations to protect such personal data.
If the reader of this
message is not the intended recipient and/or you have received this email
in error, you must take no action based on the information in this email
and you are hereby notified that any dissemination, misuse or copying or
disclosure of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by email
and delete the original message.
|
What is the status of this? Did you get a signed shim back or are you creating a new submission for 15.8? |
As of last Friday we were stuck in the 'scanning' state on the MS submission site. I will update this issue with any change of status. |
Our submission to MS is lingering in the 'scanning' state. I suspect we will have to go through the process with the v15.8 shim. |
Ok then I'll close this one, because there is already a new submission. |
Confirm the following are included in your repo, checking each box:
What is the link to your tag in a repo cloned from rhboot/shim-review?
https://github.com/ITRenew/shim-review/tree/ITRenew-shim-amd64_i386-20240118
What is the SHA256 hash of your final SHIM binary?
What is the link to your previous shim review request (if any, otherwise N/A)?
N/A
The text was updated successfully, but these errors were encountered: