You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
depot_tools/cipd_manifest.versions

499 lines
16 KiB
Plaintext

[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
# This file is auto-generated by 'cipd ensure-file-resolve'.
# Do not modify manually. All changes will be overwritten.
chromiumos/infra/crosjobs/linux-amd64
git_revision:ed616d595eb7241d39d34907050d2949121d6ae8
_vAeU0Q9lAxn933K8vDhwGK40zKVvV-yXGpIy43ATXAC
infra/chromeperf/pinpoint/linux-386
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
JNzADFRlxeTMhrtGYH5osR92-3k7u-xwHEl8zJCD2N4C
infra/chromeperf/pinpoint/linux-amd64
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
q69laj8pGYoeZ5z98ROnB7UR6FsIsKN35tz52jXoRloC
infra/chromeperf/pinpoint/linux-arm64
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
2r4PIW2n1eMDjwYPvLpt7wgn5R_jZ_i6B0GLF7XiqUcC
infra/chromeperf/pinpoint/linux-armv6l
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
bOkbRC67qIrFe7kFvKckdic2gyM58yC9X6F475Etv0oC
infra/chromeperf/pinpoint/linux-mips64
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
OUMFYNXEPkJIgRSYfpDPEBogA242p37SMezOdUusnecC
infra/chromeperf/pinpoint/linux-mips64le
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
HUOTUAGHh3nCtheVXlK_S7Rc2BEeP_S9cPLBCQs0TZoC
infra/chromeperf/pinpoint/linux-mipsle
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
LEq6iI1sL6fItvPLGHgSvKLVoVhYUmFG-RZmi2VqgIQC
infra/chromeperf/pinpoint/linux-ppc64
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
fHqOhbxkG5by_ixjDYjMCRTIWL7XlLqV-Nqm8gRZ1MkC
infra/chromeperf/pinpoint/linux-ppc64le
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
ApQ01n_k_X2V29KXY8rpjLHyaHx404zQQIwx1J_eGxMC
infra/chromeperf/pinpoint/linux-s390x
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
9zvqrZfRs-8cn8gMaSMqlHagRx-c9Uh1Gt-nWRyhUK8C
infra/chromeperf/pinpoint/mac-amd64
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
csuVZSpuY5-3djoUXCZOxpNAtAGGWGu8nMfRSqLbDzIC
infra/chromeperf/pinpoint/mac-arm64
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
k3NEHbb2zCoSEvQfyzNq87SlgMzobYFanPKiM-fBDykC
infra/chromeperf/pinpoint/windows-amd64
git_revision:8ff712069d22c33e10c26c35dbd89c55d4a623e5
cC8OGpsc20t-wH3xxLjXM16dsi8_O6My_QCpoR-4wYMC
Reland "put goma client in depot_tools" This reverts commit a0aed87f71211aff48e3c06802d173cdf21328cf. Reason for revert: install goma client without update_hook update_hook would disrupt current users, so start without update_hook, which means goma cient in depot_tools user might need to restart compiler_proxy manually when updated. https://docs.google.com/document/d/1pnwfkU6Rd9dRtQC0sg2vATmyRbkYWhnNUTD5k1PddC0/edit# Original change's description: > Revert "put goma client in depot_tools" > > This reverts commit 77780358011f8e20c68ba10aa1282f1f9f65734f. > > Reason for revert: AttributeError: 'GomaEnvPosix' object has no attribute 'RestartCompilerProxy' > > Original change's description: > > put goma client in depot_tools > > > > install goma client cipd package in depot_tools. > > > > should not use $MYPATH/goma_ctl in cipd_bin_setup > > since $MYPATH/goma_ctl uses cipd_bin_setup in itself, > > so causing recursive calls. > > invoke python to run .cipd/goma_ctl.py in cipd_bin_setup > > instead. > > > > Bug: b/77663154 > > Change-Id: I9f82c766a886a2acfb899e3594e5f05a7b7bc75a > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1866350 > > Reviewed-by: Edward Lesmes <ehmaldonado@chromium.org> > > Reviewed-by: Dirk Pranke <dpranke@chromium.org> > > Commit-Queue: Fumitoshi Ukai <ukai@chromium.org> > > TBR=sque@chromium.org,ukai@chromium.org,yyanagisawa@google.com,vadimsh@chromium.org,dpranke@chromium.org,tikuta@chromium.org,ehmaldonado@chromium.org,yekuang@google.com > > Change-Id: Ie050dfb524dd885634c31be829d733613e80aece > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: b/77663154 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1872129 > Reviewed-by: Fumitoshi Ukai <ukai@chromium.org> > Commit-Queue: Fumitoshi Ukai <ukai@chromium.org> TBR=sque@chromium.org,ukai@chromium.org,yyanagisawa@google.com,vadimsh@chromium.org,dpranke@chromium.org,tikuta@chromium.org,ehmaldonado@chromium.org,yekuang@google.com Bug: b/77663154 Change-Id: I8bb51631e4418ff63953099814bdb464128eb279 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1875982 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Fumitoshi Ukai <ukai@chromium.org>
6 years ago
infra/goma/client/linux-amd64
git_revision:8a4362219ec5a70063d54c589d6925964402fd67
_zvbiJLuuuV1h0DrZXmHoqHXRiVcaKWyUHQ-1BXgycEC
Reland "put goma client in depot_tools" This reverts commit a0aed87f71211aff48e3c06802d173cdf21328cf. Reason for revert: install goma client without update_hook update_hook would disrupt current users, so start without update_hook, which means goma cient in depot_tools user might need to restart compiler_proxy manually when updated. https://docs.google.com/document/d/1pnwfkU6Rd9dRtQC0sg2vATmyRbkYWhnNUTD5k1PddC0/edit# Original change's description: > Revert "put goma client in depot_tools" > > This reverts commit 77780358011f8e20c68ba10aa1282f1f9f65734f. > > Reason for revert: AttributeError: 'GomaEnvPosix' object has no attribute 'RestartCompilerProxy' > > Original change's description: > > put goma client in depot_tools > > > > install goma client cipd package in depot_tools. > > > > should not use $MYPATH/goma_ctl in cipd_bin_setup > > since $MYPATH/goma_ctl uses cipd_bin_setup in itself, > > so causing recursive calls. > > invoke python to run .cipd/goma_ctl.py in cipd_bin_setup > > instead. > > > > Bug: b/77663154 > > Change-Id: I9f82c766a886a2acfb899e3594e5f05a7b7bc75a > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1866350 > > Reviewed-by: Edward Lesmes <ehmaldonado@chromium.org> > > Reviewed-by: Dirk Pranke <dpranke@chromium.org> > > Commit-Queue: Fumitoshi Ukai <ukai@chromium.org> > > TBR=sque@chromium.org,ukai@chromium.org,yyanagisawa@google.com,vadimsh@chromium.org,dpranke@chromium.org,tikuta@chromium.org,ehmaldonado@chromium.org,yekuang@google.com > > Change-Id: Ie050dfb524dd885634c31be829d733613e80aece > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: b/77663154 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1872129 > Reviewed-by: Fumitoshi Ukai <ukai@chromium.org> > Commit-Queue: Fumitoshi Ukai <ukai@chromium.org> TBR=sque@chromium.org,ukai@chromium.org,yyanagisawa@google.com,vadimsh@chromium.org,dpranke@chromium.org,tikuta@chromium.org,ehmaldonado@chromium.org,yekuang@google.com Bug: b/77663154 Change-Id: I8bb51631e4418ff63953099814bdb464128eb279 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1875982 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Fumitoshi Ukai <ukai@chromium.org>
6 years ago
infra/goma/client/mac-amd64
git_revision:8a4362219ec5a70063d54c589d6925964402fd67
Katbwadhh6__8WzRcxcWWhE7MRgh2kiyNKwUHTCq2pQC
infra/goma/client/mac-arm64
git_revision:8a4362219ec5a70063d54c589d6925964402fd67
3HdtJcdr7LjxKd-InG3kzix_fcbW0FaVI831OCnEA9gC
Reland "put goma client in depot_tools" This reverts commit a0aed87f71211aff48e3c06802d173cdf21328cf. Reason for revert: install goma client without update_hook update_hook would disrupt current users, so start without update_hook, which means goma cient in depot_tools user might need to restart compiler_proxy manually when updated. https://docs.google.com/document/d/1pnwfkU6Rd9dRtQC0sg2vATmyRbkYWhnNUTD5k1PddC0/edit# Original change's description: > Revert "put goma client in depot_tools" > > This reverts commit 77780358011f8e20c68ba10aa1282f1f9f65734f. > > Reason for revert: AttributeError: 'GomaEnvPosix' object has no attribute 'RestartCompilerProxy' > > Original change's description: > > put goma client in depot_tools > > > > install goma client cipd package in depot_tools. > > > > should not use $MYPATH/goma_ctl in cipd_bin_setup > > since $MYPATH/goma_ctl uses cipd_bin_setup in itself, > > so causing recursive calls. > > invoke python to run .cipd/goma_ctl.py in cipd_bin_setup > > instead. > > > > Bug: b/77663154 > > Change-Id: I9f82c766a886a2acfb899e3594e5f05a7b7bc75a > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1866350 > > Reviewed-by: Edward Lesmes <ehmaldonado@chromium.org> > > Reviewed-by: Dirk Pranke <dpranke@chromium.org> > > Commit-Queue: Fumitoshi Ukai <ukai@chromium.org> > > TBR=sque@chromium.org,ukai@chromium.org,yyanagisawa@google.com,vadimsh@chromium.org,dpranke@chromium.org,tikuta@chromium.org,ehmaldonado@chromium.org,yekuang@google.com > > Change-Id: Ie050dfb524dd885634c31be829d733613e80aece > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: b/77663154 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1872129 > Reviewed-by: Fumitoshi Ukai <ukai@chromium.org> > Commit-Queue: Fumitoshi Ukai <ukai@chromium.org> TBR=sque@chromium.org,ukai@chromium.org,yyanagisawa@google.com,vadimsh@chromium.org,dpranke@chromium.org,tikuta@chromium.org,ehmaldonado@chromium.org,yekuang@google.com Bug: b/77663154 Change-Id: I8bb51631e4418ff63953099814bdb464128eb279 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1875982 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Fumitoshi Ukai <ukai@chromium.org>
6 years ago
infra/goma/client/windows-amd64
git_revision:8a4362219ec5a70063d54c589d6925964402fd67
lCuFpNqh5edxhMzA7zCtIGcXrLpnbLCc9fw0IVpyHqsC
Reland "put goma client in depot_tools" This reverts commit a0aed87f71211aff48e3c06802d173cdf21328cf. Reason for revert: install goma client without update_hook update_hook would disrupt current users, so start without update_hook, which means goma cient in depot_tools user might need to restart compiler_proxy manually when updated. https://docs.google.com/document/d/1pnwfkU6Rd9dRtQC0sg2vATmyRbkYWhnNUTD5k1PddC0/edit# Original change's description: > Revert "put goma client in depot_tools" > > This reverts commit 77780358011f8e20c68ba10aa1282f1f9f65734f. > > Reason for revert: AttributeError: 'GomaEnvPosix' object has no attribute 'RestartCompilerProxy' > > Original change's description: > > put goma client in depot_tools > > > > install goma client cipd package in depot_tools. > > > > should not use $MYPATH/goma_ctl in cipd_bin_setup > > since $MYPATH/goma_ctl uses cipd_bin_setup in itself, > > so causing recursive calls. > > invoke python to run .cipd/goma_ctl.py in cipd_bin_setup > > instead. > > > > Bug: b/77663154 > > Change-Id: I9f82c766a886a2acfb899e3594e5f05a7b7bc75a > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1866350 > > Reviewed-by: Edward Lesmes <ehmaldonado@chromium.org> > > Reviewed-by: Dirk Pranke <dpranke@chromium.org> > > Commit-Queue: Fumitoshi Ukai <ukai@chromium.org> > > TBR=sque@chromium.org,ukai@chromium.org,yyanagisawa@google.com,vadimsh@chromium.org,dpranke@chromium.org,tikuta@chromium.org,ehmaldonado@chromium.org,yekuang@google.com > > Change-Id: Ie050dfb524dd885634c31be829d733613e80aece > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: b/77663154 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1872129 > Reviewed-by: Fumitoshi Ukai <ukai@chromium.org> > Commit-Queue: Fumitoshi Ukai <ukai@chromium.org> TBR=sque@chromium.org,ukai@chromium.org,yyanagisawa@google.com,vadimsh@chromium.org,dpranke@chromium.org,tikuta@chromium.org,ehmaldonado@chromium.org,yekuang@google.com Bug: b/77663154 Change-Id: I8bb51631e4418ff63953099814bdb464128eb279 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1875982 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Fumitoshi Ukai <ukai@chromium.org>
6 years ago
infra/tools/bb/linux-386
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
JdUJYBAY7-VBj-TAi_1UbhnsrF8BmxnC5y5uFJRKH0QC
infra/tools/bb/linux-amd64
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
KQYkgilGGhktMxFGm_-ramensPrZZsZnEXr6rb0uiMMC
infra/tools/bb/linux-arm64
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
Y_FZxUGyZ_YcXr-FhpwYsCpaxYUNi-QXNKmb34WZ6dwC
infra/tools/bb/linux-armv6l
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
V26xnVN_1rk2WCKN-3uadIKZPvukAcaPsC3qYF-WyrsC
infra/tools/bb/linux-mips64
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
LkvMpt85kbkLQv9BBK_7yTpI1QBA6GBNk6BwYKB_MN8C
infra/tools/bb/linux-mips64le
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
BdtHoHC7h06OtQsiqLMg4z2yjLHTyjGP-tF7ZT37Mq8C
infra/tools/bb/linux-mipsle
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
9DJrhZzTS1Q58Ct0AcHigREr5i80dCoEqFXvYndLoj8C
infra/tools/bb/linux-ppc64
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
djPVD8BMizBn2lkVM2-4KxYbist_ERvRA3IZnoRBicIC
infra/tools/bb/linux-ppc64le
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
QYlzsPuZwKGYoUMoBE2nhv5DkGsBCMFKeenjEEM4r5oC
infra/tools/bb/linux-s390x
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
T2UUXfoq2o8EX8-eJTSUDutnvE2EOnWB07xKX-vB3FAC
infra/tools/bb/mac-amd64
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
I-NLtgWw13LF_gDnHtsbWu_hsdbpeNLhUhQmSfR0ZWoC
infra/tools/bb/mac-arm64
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
8IJE1qk97Uj5hj2KIJYSeFQi8hdBd5SBTty_VPJZnGQC
infra/tools/bb/windows-amd64
git_revision:0e7a6d8b67bee60fc983e6a4bd14a828654a1ce3
_hrpGUOTDT7dmw2xRhs-XzCIHeCB8jS3TCa63Q5kAQUC
infra/tools/dirmd/linux-386
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
t7BZLWVhS6-ha11SRON2R02d3Q8w036G_MUMGVqKeWYC
infra/tools/dirmd/linux-amd64
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
ryPnf5T-9nYM7XqImWtIWMAXztJdVbJvoT2S5TRXI_0C
infra/tools/dirmd/linux-arm64
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
rzX8UPoV2cRfiBEFY9ysBTjP1iAbKne1DZO8q6gwrrUC
infra/tools/dirmd/linux-armv6l
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
dw13hta8cGz-js0YbWm4D5itVHJavZmS52-bhkfkW8oC
infra/tools/dirmd/linux-mips64
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
rhSJ3dXKKO7AEelAuRlSovvnDHn8l53OLu9NC_wcx4IC
infra/tools/dirmd/linux-mips64le
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
j6xAPANY27629qu9loJ7lx9_LY0gNUlwW7dOB6_qUt4C
infra/tools/dirmd/linux-mipsle
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
MixDXTEOE3FvLs7xLt1xeZ48Fp2quOFYMwbI_NdvVd8C
infra/tools/dirmd/linux-ppc64
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
oPjQvWEhIoS0hKoPcZOlW6_IJRiKBbKFCfDJ5zYsh7QC
infra/tools/dirmd/linux-ppc64le
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
jjqwgRBvnGU9-nTUx9yJqWlm6d_iXDta1VcplnqmJGoC
infra/tools/dirmd/linux-s390x
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
KkXynAv2mPDGRtBFWdPNGBwhwJTmNaP0jqbMtxX-cwMC
infra/tools/dirmd/mac-amd64
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
Q0PlTlJmQKYYfc-R5L_axfKKSxwoYrNqbVvpdr7uIHkC
infra/tools/dirmd/mac-arm64
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
oaZkHTNVlG1SJUpALRDlubF-bDQM3pL9y_TqoyoZOeoC
infra/tools/dirmd/windows-amd64
git_revision:94b7072314e9add48e9ee0b861d387a8972805ef
-FuCHOpigYnD9_i2hqeZIWjeDkaFqOwH-xEqUVAXOHMC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/linux-386
git_revision:297491c0babda68d84d8240c9d4504be671bc804
eP17h5YJMrU6hWBOvjZxWCz5h9SgkkW-vVF7W-L9qwIC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/linux-amd64
git_revision:297491c0babda68d84d8240c9d4504be671bc804
Xf6nFp5RbFKQLUk7d3O5LKPmmdnAF8NU4NsoO0QGP1UC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/linux-arm64
git_revision:297491c0babda68d84d8240c9d4504be671bc804
owOKUdyWr11KyfuCRigGRsBM7uPnOMVrH_WOMYYCGJYC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/linux-armv6l
git_revision:297491c0babda68d84d8240c9d4504be671bc804
iZa8O1smpKFTta3pQVz9TaIOlRIu31V4QPgGbIVkCgYC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/linux-mips64
git_revision:297491c0babda68d84d8240c9d4504be671bc804
s6dXt6MAJ8kreqm79HyghgHg9mk93u8ju303d1RIZ4cC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/linux-mips64le
git_revision:297491c0babda68d84d8240c9d4504be671bc804
K2S9QpIR4701H7N2E6Fm9iGCOg8hwa3mY51S1CmrwdEC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/linux-mipsle
git_revision:297491c0babda68d84d8240c9d4504be671bc804
0jLzmuxOsRVyYofMKQfgivPZOtxsXv0Slcr1dRU78UgC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/linux-ppc64
git_revision:297491c0babda68d84d8240c9d4504be671bc804
7SK4rFVEOeA4CqHD0mKebTOCx7viE-dJMakFqE6W6BsC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/linux-ppc64le
git_revision:297491c0babda68d84d8240c9d4504be671bc804
ZruNFqBhC_reTL2dw3wf-t17dc_sPZJ_733R6BLBvMsC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/linux-s390x
git_revision:297491c0babda68d84d8240c9d4504be671bc804
8q6NmriGR1GiT9e-UlHeau2VMkcN0UYumU8AVDLIsZMC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/mac-amd64
git_revision:297491c0babda68d84d8240c9d4504be671bc804
pxk-T_GADDuTTtmbUsK3TlMHbsMD8jb5Dt383XPmeeYC
infra/tools/luci-auth/mac-arm64
git_revision:297491c0babda68d84d8240c9d4504be671bc804
cR0PKTchP7f5iIXZdCSffnp_p1_ySee-16Gg56qhxqIC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci-auth/windows-amd64
git_revision:297491c0babda68d84d8240c9d4504be671bc804
McEKBb2FM2gMj1og3guOfA_jd690eGivhdSbKP90ruwC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/linux-386
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
lWjGVEgjiCutLJwWt1c1JDQcWLqI3prl1CBWrtGs5IIC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/linux-amd64
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
l6Un3jXqLZKuFALfOTL_JfCfEgaOsq30m61GdkU8cqcC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/linux-arm64
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
kXldjGIPID5O1wiKdsOd6wHMJXs7DmXk2nAZnBE6qz8C
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/linux-armv6l
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
Hwj4DSTbf6EqUpfYF2obO9BnMjGxvV3GQ8MlnAY5cH4C
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/linux-mips64
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
FThLC_1w626SxZuQx1FxM1W83se3opx0uVrKAhcivVkC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/linux-mips64le
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
eGjcnd9mUeGImFRmjmlQpesDNwiQUEhDldq8jgASWlcC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/linux-mipsle
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
kfBKAthu9U8cwxTJAKIFwqOmMeB6gFWs8KKxYcRlgxwC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/linux-ppc64
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
RhQmoXf1a5xq1WzM2R6asTnsYNRNHbYFyn00vZcP94YC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/linux-ppc64le
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
BLqKMn56d9AA3illmfBoW-pV5Aa7UcKUSr8Dojxqkx4C
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/linux-s390x
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
sY5dpQPlMUCCrTYdHsKoJSD6R5K4AK9lWjUQdre_ebYC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/mac-amd64
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
cHhI1aMJcPpOMwk0GvmuG1HIuiYCiKIQKWMn36cqYlcC
infra/tools/luci/led/mac-arm64
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
hhPgL3y6n5lLonvbl3C7B16h6U-lrjZSyiZDc9oWqbwC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/led/windows-amd64
git_revision:a2e97300d3ad30cfb9bb5399a98d603594d8073b
zaObwxbvvpxnc80ZTjl6_P6grHy7XzwvXpWsUj_SRZcC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/lucicfg/linux-386
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
WAu_fxzas2yEFISN7FhQyZEaXHF_79-0fY1ABjDZLLQC
infra/tools/luci/lucicfg/linux-amd64
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
_Om_YMXpunEzCCXbzaB8fjC9NizYwnnLqz1kohYAKvQC
infra/tools/luci/lucicfg/linux-arm64
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
wUo5BeFxGzBDBg1Y5l_RcfEBBy-hNTl-ZULK7DgV9zQC
infra/tools/luci/lucicfg/linux-armv6l
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
5gwT2_fnj8qjOq-s2dniohZ1dddF1HyUba_qFMLE8UwC
infra/tools/luci/lucicfg/linux-mips64
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
Kso7kegGaU7WaGXdQjbmLChP4pPGxMjXrJ4ypkbvBA4C
infra/tools/luci/lucicfg/linux-mips64le
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
UPdcHf3XsC8b9gfS7OE3ZqDJwt3vMzPOVw2VQqiWt1AC
infra/tools/luci/lucicfg/linux-mipsle
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
7agSkrzbzqj6i0ElPO8OHXFJKP1JKNyZq-MYxd7IjLUC
infra/tools/luci/lucicfg/linux-ppc64
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
bPqnAaL9wFAfLN4_clIt-a2R95j8PM9T2Lsandy_hNIC
infra/tools/luci/lucicfg/linux-ppc64le
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
SEEGhA8UGCytUT4uluO61GAR7Ow8fHk8AbDg7Cl51bcC
infra/tools/luci/lucicfg/linux-s390x
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
YnAZV1cuqBfRiCkhHlvvGZVcf7PSSyUGLP9gCK0Nr8YC
infra/tools/luci/lucicfg/mac-amd64
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
bJ6gWyid2-78MpetKbR6J3wE1OO5UOYnZLxn_Y3Tv_YC
infra/tools/luci/lucicfg/mac-arm64
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
VawHjaDlN-MxdFO7lBZRhnDayZwuoomsdrf9DIjr49oC
infra/tools/luci/lucicfg/windows-amd64
git_revision:75889f130cd80d6b60e3f09d0c52fc5ad55eee24
bVvh2GthhTVS-IrLyg7g7Qi_QKkyZWHD0P42HY9Z78MC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-386
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
-NNJV7P4ZTGj3Kvbz0g618uKKopt2ou-HwytSnCIzFcC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-amd64
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
2CSRpNEktLZlZjlfxto2-T_AJdCWvL795J5x3DfC7MoC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-arm64
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
e2QPO5Kx5DC8whwTNX46-cPq7q31xV7bt-_YBdewc-QC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-armv6l
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
3HviXYnHjgzp9yV-WFb1-9-k0Ptvmt1boB4oKimwTeMC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-mips64
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
OnD3TT9_troKCu7x6P2oPRbhTuNkTcJ_5hvzoXtvDe8C
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-mips64le
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
uY2ou_9vn83khYfygQu9dhNOWbfyxMXWfSVftI99y_MC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-mipsle
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
c-sNAXHUEBNLEsHVMIjJ_B_7QBuJ0tQUjfELA5I1yQEC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-ppc64
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
3loLzxf5jp3U4YErdIudIwjjqNHiRGpXVxsfDBAFiqkC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-ppc64le
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
WkcwXQvytXsHKikjI-RgxoLrSbRiyqa2bvkp-af9vuQC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-s390x
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
vmu-XPgQz1wGeeBEXY-RZFsJ9_eOIpXQs_wBjsIlH8IC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/mac-amd64
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
3_X_ZZlBRQt-cItySuWRdfRy8C7J8ShbuP4Oymc3coMC
infra/tools/luci/vpython/mac-arm64
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
S23DFNfG6lnCiWMW1OLcTI-jk9fHRhvJxzxuk4t4GqYC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/windows-amd64
git_revision:fa83de432d2cad5b196b51ad8fd9a0592e9bdd52
Qob010uWn28hNYORkeVDosNo_WuDek_SSRZrfsOCJP0C
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/mac_toolchain/mac-amd64
git_revision:723fc1a6c8cdf2631a57851f5610e598db0c1de1
2ozLryqklxu4fc7KZr_EqEpL66z0G0moWJef2qnPXXwC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/mac_toolchain/mac-arm64
git_revision:723fc1a6c8cdf2631a57851f5610e598db0c1de1
1VL13oNQ2PA-Ez2iYTQOWHFcXwA9UD_nhKdhqXsJw-MC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/linux-386
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
0jh5WJiKY3YuD_Jb8PqwvoEpkIErWxDjPK1zHJt7AWsC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/linux-amd64
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
ifuMgrBw52FZoNeCoOOBKJnEOVZissbo16oyfdNNFR4C
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/linux-arm64
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
37GBPQH01OFQ_mNexmZL4JXvTJrJZ6lupI2oipo7NygC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/linux-armv6l
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
p5RXqsNOyauZgCE7fUiaJjjvfiyOaduXWxsPi79jSusC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/linux-mips64
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
5vO0g5QLGwZINTFQjnhKEEMDTaQ2geUUP16w3T7icicC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/linux-mips64le
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
FV4lcmPr2Y3qx5dC85IxvN6j26tgBTIZY3KL3OO6ggQC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/linux-mipsle
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
ZLw57efe_OTsHW_Sl5W2tK29zOx2xEi7m6XqQVEAS6EC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/linux-ppc64
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
1KLg18xHw43xbVYfPMPXBhqANzzRwP3aYRl0wi3qohIC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/linux-ppc64le
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
hKB-qdoedy6YFlpMY_B2sNmhdoJzQbcRRU-ivr_nPZsC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/linux-s390x
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
Z8errTmVek00stSE8njJ4agFHThZWdziTgN5qpNDFbcC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/mac-amd64
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
SyQL0RzHkWotXKicxXx49tVIBYW56N-NeDSB046eXwkC
infra/tools/prpc/mac-arm64
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
M2wFOESsz-1S_BtbL2dKzUhxAspQa1OolA-J954ggjQC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/prpc/windows-amd64
git_revision:5a038afb97f6b77e0fcefe1185317da216fced1f
pZ4PpzsgPaEjhtfUbbynrRQQ6e7zNBnEWnKn6aupqyQC
infra/tools/rdb/linux-386
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
R7rEdwhM6KMO-bLlPQscu7P-UVqM3xlumqr9vvi3EncC
infra/tools/rdb/linux-amd64
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
y2RwvR_NY-gITzTR4HD01OXx20yD4qthXYST6eubEJYC
infra/tools/rdb/linux-arm64
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
Ba1muEd9VQoVbSBKpj4qh0M0M5uUsdBDFJZvq-RN-OwC
infra/tools/rdb/linux-armv6l
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
ZJjdiNekm3ZN7V3I3YYJFuBJ_Pvy_j3o-wQCq4UwqDgC
infra/tools/rdb/linux-mips64
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
pHLG131TuW_iIybx5TltE1FQStEUtt7DdOhu9cn9rDQC
infra/tools/rdb/linux-mips64le
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
eypMmgNkdyyfCrOamDQZAaLDqoUAEwFTL_aDe4iiP6sC
infra/tools/rdb/linux-mipsle
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
azuk1r35DtMtfgqtBwlFoMbW3tDMKMo_em_Ays7qqNMC
infra/tools/rdb/linux-ppc64
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
tu1H4eI7cCmDZT1ONDYUu2ARmSaqvL17yi9LUfBxDXwC
infra/tools/rdb/linux-ppc64le
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
JNIGWz1RIdu3K4Db5QvXFB1lCLRBD-fKhEyaz68xLQMC
infra/tools/rdb/linux-s390x
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
VGuoL235VqWEL1P2enaNz8fe-T_hbNU5qLY5VsVKmr0C
infra/tools/rdb/mac-amd64
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
Y_H0AySu8O5FLpB9t8vqYAFtrkwRRqG7urrjmRzbyf8C
infra/tools/rdb/mac-arm64
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
ylQe7rPPYIn7yQ2x1NwlU55DH5Karq7v7-XNPxjP_6QC
infra/tools/rdb/windows-amd64
git_revision:2be056d01d3f8bab07915a1c2eca04f1937ad833
9r6QPQmkPAbvoCEAADMFk0OBP6kUSicxFQYgJMbUlysC