Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2145603002:
Update UDIFResourceFile struct definition with code signature data (Closed)
|
Created:
4 years, 5 months ago by Mark Mentovai Modified:
4 years, 5 months ago CC:
chromium-reviews Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionUpdate UDIFResourceFile struct definition with code signature data
In https://crbug.com/620831, I worked out how code signatures are added
to .dmg files. These signatures can be added, verified, and displayed by
codesign on 10.11.5 and later.
This adds the fields to the 'koly' block that point to the signature
data, but does not process or interpret the signature in any way. The
UDIFResourceFile struct in udif.cc is a more appropriate location to
maintain knowledge of the 'koly' block's layout than some random closed
bug report.
BUG=620381, 627605
Committed: https://crrev.com/ca55c1b22e7d29645ce9a5396b0d778bb1ee024c
Cr-Commit-Position: refs/heads/master@{#405023}
Patch Set 1 #
Messages
Total messages: 19 (6 generated)
mark@chromium.org changed reviewers: + rsesek@chromium.org
I thought we had an OWNERS file in this directory.
On 2016/07/12 15:43:02, Mark Mentovai wrote: > I thought we had an OWNERS file in this directory. Maybe we should. I should also split out the BUILD.gn file to add crdmg too.
LGTM
mark@chromium.org changed reviewers: + nparker@chromium.org
nparker for OWNERS
lgtm What will this be used for?
On 2016/07/12 21:10:39, Nathan Parker wrote: > lgtm > > What will this be used for? We may extract this in the future, as in the upcoming macOS 10.12, Apple is introducing code signing of DMGs. But at the moment, it's just giving semantic meaning to these previously reserved bytes.
Gotcha, thanks. We could have Safe Browsing whitelist certain signing keys like we do for .exes on Windows, to reduce the spurious warnings. On Tue, Jul 12, 2016 at 2:11 PM <rsesek@chromium.org> wrote: > On 2016/07/12 21:10:39, Nathan Parker wrote: > > lgtm > > > > What will this be used for? > > We may extract this in the future, as in the upcoming macOS 10.12, Apple is > introducing code signing of DMGs. But at the moment, it's just giving > semantic > meaning to these previously reserved bytes. > > https://codereview.chromium.org/2145603002/ > -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
Mark: the BUG= and crbug link are incorrect, btw.
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=627605 to track this improvement. rsesek / @chromium.org On Tue, Jul 12, 2016 at 5:17 PM, Nathan Parker <nparker@google.com> wrote: > Gotcha, thanks. We could have Safe Browsing whitelist certain signing > keys like we do for .exes on Windows, to reduce the spurious warnings. > > On Tue, Jul 12, 2016 at 2:11 PM <rsesek@chromium.org> wrote: > >> On 2016/07/12 21:10:39, Nathan Parker wrote: >> > lgtm >> > >> > What will this be used for? >> >> We may extract this in the future, as in the upcoming macOS 10.12, Apple >> is >> introducing code signing of DMGs. But at the moment, it's just giving >> semantic >> meaning to these previously reserved bytes. >> >> https://codereview.chromium.org/2145603002/ >> > -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
Description was changed from ========== Update UDIFResourceFile struct definition with code signature data In https://crbug.com/620831, I worked out how code signatures are added to .dmg files. These signatures can be added, verified, and displayed by codesign on 10.11.5 and later. This adds the fields to the 'koly' block that point to the signature data, but does not process or interpret the signature in any way. The UDIFResourceFile struct in udif.cc is a more appropriate location to maintain knowledge of the 'koly' block's layout than some random closed bug report. BUG=620831 ========== to ========== Update UDIFResourceFile struct definition with code signature data In https://crbug.com/620831, I worked out how code signatures are added to .dmg files. These signatures can be added, verified, and displayed by codesign on 10.11.5 and later. This adds the fields to the 'koly' block that point to the signature data, but does not process or interpret the signature in any way. The UDIFResourceFile struct in udif.cc is a more appropriate location to maintain knowledge of the 'koly' block's layout than some random closed bug report. BUG=620381,627605 ==========
Robert Sesek wrote: > Mark: the BUG= and crbug link are incorrect, btw. Thanks, careless transposition. I fixed it and also added a reference to your new bug 627605.
The CQ bit was checked by mark@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Update UDIFResourceFile struct definition with code signature data In https://crbug.com/620831, I worked out how code signatures are added to .dmg files. These signatures can be added, verified, and displayed by codesign on 10.11.5 and later. This adds the fields to the 'koly' block that point to the signature data, but does not process or interpret the signature in any way. The UDIFResourceFile struct in udif.cc is a more appropriate location to maintain knowledge of the 'koly' block's layout than some random closed bug report. BUG=620381,627605 ========== to ========== Update UDIFResourceFile struct definition with code signature data In https://crbug.com/620831, I worked out how code signatures are added to .dmg files. These signatures can be added, verified, and displayed by codesign on 10.11.5 and later. This adds the fields to the 'koly' block that point to the signature data, but does not process or interpret the signature in any way. The UDIFResourceFile struct in udif.cc is a more appropriate location to maintain knowledge of the 'koly' block's layout than some random closed bug report. BUG=620381,627605 ==========
Message was sent while issue was closed.
Committed patchset #1 (id:1)
Message was sent while issue was closed.
Description was changed from ========== Update UDIFResourceFile struct definition with code signature data In https://crbug.com/620831, I worked out how code signatures are added to .dmg files. These signatures can be added, verified, and displayed by codesign on 10.11.5 and later. This adds the fields to the 'koly' block that point to the signature data, but does not process or interpret the signature in any way. The UDIFResourceFile struct in udif.cc is a more appropriate location to maintain knowledge of the 'koly' block's layout than some random closed bug report. BUG=620381,627605 ========== to ========== Update UDIFResourceFile struct definition with code signature data In https://crbug.com/620831, I worked out how code signatures are added to .dmg files. These signatures can be added, verified, and displayed by codesign on 10.11.5 and later. This adds the fields to the 'koly' block that point to the signature data, but does not process or interpret the signature in any way. The UDIFResourceFile struct in udif.cc is a more appropriate location to maintain knowledge of the 'koly' block's layout than some random closed bug report. BUG=620381,627605 Committed: https://crrev.com/ca55c1b22e7d29645ce9a5396b0d778bb1ee024c Cr-Commit-Position: refs/heads/master@{#405023} ==========
Message was sent while issue was closed.
Patchset 1 (id:??) landed as https://crrev.com/ca55c1b22e7d29645ce9a5396b0d778bb1ee024c Cr-Commit-Position: refs/heads/master@{#405023} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
