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

575 lines
19 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:bd3a982ae62b4820b71414b2340e86019a1fbd26
O6ChffXAafn2KNzLFlddCOEI-UPJ3Jg8BjNhoCcQRYUC
infra/chromeperf/pinpoint/linux-amd64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
Ufsh7Be35nTha4HSYeWCX3aUdzDMUmj73-OwD41lscEC
infra/chromeperf/pinpoint/linux-arm64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
5sj1Sz66UVmm-Q8wQH85flz6iuVP4kqsRrp_lMxLEhAC
infra/chromeperf/pinpoint/linux-armv6l
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
S_VnGrTQIcCy5sRDLmURowwAzVJbPLTAtlJJzt4WSlMC
infra/chromeperf/pinpoint/linux-mips64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
ztUE3gRvvhdBRP8XPcumLBctolAds5dSLNTmrEND9KUC
infra/chromeperf/pinpoint/linux-mips64le
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
FVFoczG2ycsHVtWIyTf421eucm_Hxv77PGvyotracKwC
infra/chromeperf/pinpoint/linux-mipsle
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
67A4bL-A-wCJ5zqxHheBPbi79TGRORMT5YIjpHVRfz4C
infra/chromeperf/pinpoint/linux-ppc64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
m5mIhauex3Alscr4wLmF4ouGlr7wi2X0QHcT3kCFzbgC
infra/chromeperf/pinpoint/linux-ppc64le
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
yzy_QfYoWJIXxnrgRKQxM0o54OrkfhCy63kVU5bC_isC
infra/chromeperf/pinpoint/linux-riscv64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
re_gd_snZkAiqFjZ8L02IsN0P2EjqeqZ5gnXXgxLT4kC
infra/chromeperf/pinpoint/linux-s390x
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
1H-JYzH7DPNpCdr1zNKwtt0N6QnF2RadShCAKENp728C
infra/chromeperf/pinpoint/mac-amd64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
SlPCkUcb3EIvgazMeZNGVgq84Qn8wodE1YEBbvgq08QC
infra/chromeperf/pinpoint/mac-arm64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
l4AehfpPb5LR_kqui-WCQX6sySymCuIdOLFFUTr1R7cC
infra/chromeperf/pinpoint/windows-amd64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
7lZuWtQZUHpdpKp_JPVx0F8vnkyAJiiFg7talumnf3IC
infra/chromeperf/pinpoint/windows-arm64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
pJxQ0Hl-ATP8eyFijAa3xaYIms_8nfXxSX07XVxyKIwC
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>
5 years ago
infra/goma/client/linux-amd64
git_revision:603dfba63fe365a01879029588b48b6f122fe0b8
QZEdb4w286MM6sd9ALcXw36jDYQY9S1Vma5cfyQF8Y4C
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>
5 years ago
infra/goma/client/mac-amd64
git_revision:603dfba63fe365a01879029588b48b6f122fe0b8
t2mJ5uhpan9AXxG0D-h5C5IOfz4ZUNjGV5UzsZnj6JUC
infra/goma/client/mac-arm64
git_revision:603dfba63fe365a01879029588b48b6f122fe0b8
sf__pdfvHmVZLaWZ9Px92vfrxu0Kc7z6YmwiiLe-wsYC
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>
5 years ago
infra/goma/client/windows-amd64
git_revision:603dfba63fe365a01879029588b48b6f122fe0b8
TsKkiGBqIo_4FByeFHO6k_8We2PKr4agbEcShhxHd6MC
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>
5 years ago
infra/rbe/client/linux-amd64
re_client_version:0.124.1.13f78cc-gomaip
LCOZhNACP54nV-xYsKIGGOzlFnVyacNwmv4YzqxxgOYC
infra/tools/bb/linux-386
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
N9nQuqLy8iLZY-qU5Odg1QLMKA7fBZw14ChzP6BbC9UC
infra/tools/bb/linux-amd64
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
HH8MAsY2V5cHWka4DjGvYPeCuYABVfy0jmQyLgmuyvUC
infra/tools/bb/linux-arm64
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
eZg0j2IlVBW9YhuB87N_53DdGILiFtxT8XEkdx_VCTMC
infra/tools/bb/linux-armv6l
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
dpHAB6myTRlcJYpw-2EzcUXaCQyJeDOIMHiwEPUEV1cC
infra/tools/bb/linux-mips64
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
QH58VVNy6fcrF_6w400Sg_nryBLAbVbNv6F_DAE6xMwC
infra/tools/bb/linux-mips64le
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
7HPApWY4HoXZ7XiSrgmWT2-2IOJTjaBH-ULG-HOPjEkC
infra/tools/bb/linux-mipsle
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
OE5RHmGQbuLW1QFl_2SMebSS2xut5uZ4wtWnPoVilwQC
infra/tools/bb/linux-ppc64
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
Rt5scP_9R7A5FNNi39hXhxkJmE0ue05rYzuVut-6GyAC
infra/tools/bb/linux-ppc64le
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
UKpUT12II0gMWoU43bKgxnMiJyKadKNEwRIIOxpxZ_YC
infra/tools/bb/linux-riscv64
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
1qa6q87EokDSFQJNeIb5Po4oACi3S7h24YVz5zke39IC
infra/tools/bb/linux-s390x
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
7fruWKiDZ5sRoYql5lIDTfvEPbb629g1zdrOeGjBdHkC
infra/tools/bb/mac-amd64
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
YdUerVH4Uz_NMErYFMy9ct2-lGSuffe1_JWvtSthy4oC
infra/tools/bb/mac-arm64
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
ebKsNVnssT9n0URewx4DiBik-vycVaecIW6L4Lj4HCIC
infra/tools/bb/windows-amd64
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
WrozlgioeqqmhtjJjB3OiOoYFb-L-zcxzm-dMv0WargC
infra/tools/bb/windows-arm64
git_revision:b1ef34e3c86269b1261ccbc039ff2cfe3baaa961
OlF3pZB7sxFSV_m6_SETa6lI7KhzCiL3ut3JV0Q6wF8C
infra/tools/dirmd/linux-386
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
u08j-6ZdnY1jYLeRsfU_9AJ1TDApSykOfdQjDZphylUC
infra/tools/dirmd/linux-amd64
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
-TSbLePCLnpfZ22Psg-vmZrh7mx5S7RCujkx6R_ev-QC
infra/tools/dirmd/linux-arm64
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
u6_AXINx1AL_jc8gYUSMEdpIMj2C2M6FaUeF6O31Z2gC
infra/tools/dirmd/linux-armv6l
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
3TLxxdCJBoPHWYi1IQiBUUeKcjRbBa-kU4o0FnUDzhoC
infra/tools/dirmd/linux-mips64
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
0fkBBru7CB6p1-XHliXwJuK98CguIQPuNRrmPZHhPjEC
infra/tools/dirmd/linux-mips64le
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
lV4kVLI30z_4u1lt24lheTAtfWjyCxKJQ3idaqTHSIAC
infra/tools/dirmd/linux-mipsle
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
ZisX-rxLqSW2oWiit7i9sSMXY4g3qMW8wmrUErANDsQC
infra/tools/dirmd/linux-ppc64
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
Im_qwKK3C9xndTycfNOuBAWma7dfr_OS-E0KfeVmvlUC
infra/tools/dirmd/linux-ppc64le
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
_yGwTPgTwe4s9A9-bKWDSVKqq1xcxDmlGf3qEwY6tnIC
infra/tools/dirmd/linux-riscv64
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
nt9rhHAcKsu3nN52NWZx1SSRH8X_NRa27UYHcUh_l-gC
infra/tools/dirmd/linux-s390x
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
ZeauswrR0W456TqegV7qz7B7B-ZUJSO5whnLRFDnyrIC
infra/tools/dirmd/mac-amd64
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
4y8cA_5h-XRBDQmD1spCdwj9Fnd34y0yeABnvOLBVNMC
infra/tools/dirmd/mac-arm64
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
tlw_fdY8MmzLE-avT8CZx3VqZqTi2wAwAzbKpwgXlEAC
infra/tools/dirmd/windows-amd64
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
f0LWxnahbRqTjeaPLztCJLbAnpOyTIF0bHDE2RymsHoC
infra/tools/dirmd/windows-arm64
git_revision:9558e2c2dc002209753b8e61b83c4a2c81361fbc
Cfl9B4JQG13noONuyS3NIS-6qzO0T8H8KHGp1xvJqbIC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
bItU6o-pcQcGlr_iExBuVYn8XNHYabtcuxyEh0QYas0C
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
gYFNeAfhybbBS0WHac3cdfo9R4ThdVNqVcFw2LTyW-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-auth/linux-arm64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
ad0WSrIrsC3mEztSSC5CDaLd1QzS8rzc7_HhY9Q4DSUC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
_N-w3kLenV5ibdp2ahjdMd5i5zaBJD7SR-B9PJ7M8NQC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
X9mNDThgzmpkngUo9I8HepJIJIS-2gAPjCuZ3dY1x8sC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
p7H2F9oktpS3dUtq4U1ggLCiKoAxeTv96_IyuavVkAwC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
XpO_JGXVpBZzcDhDThRT9TDrS1FtD3TB-psb8OoP1C0C
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
Uv5W0qRRKJT0MsIXxjy7Bvh9TFx_0zgG21QqdUTmrHwC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
iA4CtM3ElULxax_xXXdtMIrMOOiCrRPiOmQx2kzZgsQC
infra/tools/luci-auth/linux-riscv64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
UKU7cXl5fHVDZ1FQdEecr6fAliViJsteSpOZf3foNloC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
mMMavlRub12gKqn0rpT9dFQuVLOD5yphQuv8SbZ8e2UC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
UdNQrfV_v-Wa6pMYkuIbJNKMnRTIq-BhbPyA4IGBaHIC
infra/tools/luci-auth/mac-arm64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
yEuESDIVsPTJEw8C79u0PbZ1Tf6SukVshSMgY4NRJ-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-auth/windows-amd64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
Hsws1hpsh_jRxLWYT7UrN05UqmvUE0l-csfyF_wgQv0C
infra/tools/luci-auth/windows-arm64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
gVGVpeHnRmY5YSLIaJwNs2Co26HANIHbV6EdeY7CnQwC
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
3QwzNVZafY4FpDWqc1HX5AGCaYMy8mYbSe3xnjjZCZgC
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
-tZ6paO0dbl9ligjqakzFNLqMrX2d6TKZ6CmFY-2g5IC
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
iobvNCdZxSCExloO3Pjk0BP1P_281MV_Q-ret_iLTn4C
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
d_d769MEf2tKVAyWTZK-keFMdnzm1a_3ZaXi6_YKoj0C
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
t5o3J_0wA8thdf43E4F2fv8BrDKJx00App7FClintU0C
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
6FrKh-rJgpzQvYxbRw1s58qmqMWtP-XYrF9756R9UGAC
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
HFMKi-pngJ1DdgN5hNW8PJSNfchLyWJxyosRrkJpm8gC
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
JHl6JCzaKRNNWqHMhqGRnSkxBMf74_SEBVsISFUWVDYC
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
yjcNifWIpTVp52Et5KmoJGOGz39n5_2pRvgscro5wdoC
[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-riscv64
git_revision:3533cc64973555e09249964c6efbd8ad8a53f53c
RjumQo8MZrIyuDu7cDt8sMOS798_WCua9OJwZ9j_zpEC
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
j-kgXFbYU_OR0cB291r_tIRGda6yM2ItAxvP3lO0OQsC
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
j_-YgMJtdz7qQ9LUbtVJWNcsLDuK1-RaTsszksefel8C
infra/tools/luci/led/mac-arm64
git_revision:3533cc64973555e09249964c6efbd8ad8a53f53c
x9PiTfE6Z7OmIGx2E_HvoxBCMS1U7OHq2e-rVsjO57gC
[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:3533cc64973555e09249964c6efbd8ad8a53f53c
w2qOKXh9vEGLDbsdezfNosgSkGASPW4Ok841dPGe6nQC
infra/tools/luci/led/windows-arm64
git_revision:3533cc64973555e09249964c6efbd8ad8a53f53c
3EJbGzn8E0P8ISneALH0PF8GML7b2Ov6KlNG2fiJ_wQC
[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:6a4656842fbff0654cb743b53ac95a9b5986509f
m2tUFpFBtszvxhryUZ_Q2nFa_WnD7KwbO46APSNeTsoC
infra/tools/luci/lucicfg/linux-amd64
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
yD0hYpYWkgMjQBMqhrf6wO6nxyAjKHSOJLrRFz9H4SgC
infra/tools/luci/lucicfg/linux-arm64
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
AuuT9V26IwZoVBb4pnskI1udTQaQ83EK4BYpaXUyfhgC
infra/tools/luci/lucicfg/linux-armv6l
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
FbtbLA7pr4epZkVz3qt9S1f3Vxkq83XWfWpISD-mXOEC
infra/tools/luci/lucicfg/linux-mips64
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
kPZCUOMPc6wQ07Y2-SB-M9ss43TJkJA-TYxX1ue8SMgC
infra/tools/luci/lucicfg/linux-mips64le
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
_UAVPyeMYyRDrI5LUCRlebWnMJouKSJrfzcDtwOwmp8C
infra/tools/luci/lucicfg/linux-mipsle
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
tPYao4z5sB5bILSqLur7LNUFpOIFqUd7i1jRo5j4esQC
infra/tools/luci/lucicfg/linux-ppc64
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
eL8uAhCxFPnKsSD9CuucL2mpNc4fZd8zAoL2E7wB9XAC
infra/tools/luci/lucicfg/linux-ppc64le
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
m5V94zaPy3elYx4xQywRtpiwVcuR9Vw3rWwJqq0lNAsC
infra/tools/luci/lucicfg/linux-riscv64
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
MFoXlwkR2NF8irIGu6hhFSR3YqPwaH307tLhBD2hT24C
infra/tools/luci/lucicfg/linux-s390x
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
K2ylISvcO7VALYORNB3kmnNxZ60537y0I3xqhYe7bRwC
infra/tools/luci/lucicfg/mac-amd64
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
PXfDbl1hxbOysi2pz1mvn4P7S3Rd6I2oNWSMCe7v98YC
infra/tools/luci/lucicfg/mac-arm64
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
pUNhYEM6RKBRO0RdTpzb08v25u1cDS33XI1iHDMWdbkC
infra/tools/luci/lucicfg/windows-amd64
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
FPy2i1sqQ2vOATO2dlqFKZzoIFe2FgnVmxebzp-xwVsC
infra/tools/luci/lucicfg/windows-arm64
git_revision:6a4656842fbff0654cb743b53ac95a9b5986509f
oVYUiA4SgnzWLYuKWm0dEj1GClfXckhcoQNOnyZtRUUC
infra/tools/luci/vpython/linux-386
git_revision:7590083e9549cb9951034da4183ca227e3ce287b
b5FYoVjM9uRs_ahld5zEvfiWnIq2bg3QRIRRgEwRErQC
[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:7590083e9549cb9951034da4183ca227e3ce287b
sPBrhE_Oq0jFSm1X7qwRdQVZsqjm_dh0opOuyQ60W_cC
[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:7590083e9549cb9951034da4183ca227e3ce287b
xkX5QETiyWIlvYXVm1IXtxn5SO7u8Qwqt-jhr1ZU9j0C
[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:7590083e9549cb9951034da4183ca227e3ce287b
HH_flhED4QujkGuPzDjdIGNPgjDBtIrB-Vf_MfhAyrQC
[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:7590083e9549cb9951034da4183ca227e3ce287b
NUS0W51_4T3fNj1krKMAjN1aEIMzvmbAQOX4Pp1AL1IC
[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:7590083e9549cb9951034da4183ca227e3ce287b
KKaRBtxxyFkDsBCpp-URldZSlXG0r3vubn2nt7kNRL4C
[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:7590083e9549cb9951034da4183ca227e3ce287b
wAMxOYUSY8yeiAdVXhBo-o0CQWsjmvk-vdDsHLxyeKAC
[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:7590083e9549cb9951034da4183ca227e3ce287b
yerqVwCGs3yetFOaicEmjm2uQ_jHNxZdU-Nv7wpaE0wC
[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:7590083e9549cb9951034da4183ca227e3ce287b
Zrfa57iIh1h96gzGmj96WWEqGsd02mik2MetKrf_BZkC
[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-riscv64
git_revision:7590083e9549cb9951034da4183ca227e3ce287b
roBGmCEhYkR4r3fFlx5tvkdMmb4lqJuQQgO-g7v2qVwC
infra/tools/luci/vpython/linux-s390x
git_revision:7590083e9549cb9951034da4183ca227e3ce287b
Id5I_J4rtiJ50zDu1OcCZ7DN8MdNNh5KHkliRR8xRwUC
[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:7590083e9549cb9951034da4183ca227e3ce287b
6nxfOwxAF6ldzO6G-nl-x_-m2NWKyJ7fDqa5LRsOCCsC
infra/tools/luci/vpython/mac-arm64
git_revision:7590083e9549cb9951034da4183ca227e3ce287b
3_qoBuU89qbiQB9E0AVVobdGuyIqqkgiR-reo3a7SzQC
[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:7590083e9549cb9951034da4183ca227e3ce287b
oYwZAfM76-BKFtwCuOknYYVUj3eXgrtNwsb8fPH5Ui4C
infra/tools/luci/vpython/windows-arm64
git_revision:7590083e9549cb9951034da4183ca227e3ce287b
dKjEO5nkbsEcKcIV6jnhlHIURJY5bVe8YBjdNDUKFg4C
[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:05fe195bf77656743f3daa99d463a794260b429b
1NcxKh1FggudsW2m-k6yEZ_Me2sObodtag7de6Z_D6AC
[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:05fe195bf77656743f3daa99d463a794260b429b
maNrol9N_NRlbWSCnjpV7aQMBfxoBEhtoCeCW6ORpOAC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
SLJcDJyN1t5BR8szKiRDw39W9YOun1Bfzig0uBImW0YC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
A882JTDDbItEuRH8t9gFx9Pq8uOfpIMl5eAim3Ze_oQC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
BABpEN_EmifauxYOkiOpVttYeatWaPnSry7RmR28a0gC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
cyHtQ7iqXUDicPoBp1_3MeqzHymU2gSq1L0HUAFzp6IC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
tI3j6aBFXgzODwi6b6eJmjSCgfcCqBYvRwjlUpS4WrAC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
YSfkEbA1Xx6nxGqw-VQtIcznnDk1ren9NWl47YgieycC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
eP9TrN_x5dtgf5lzizrs7tH3F4Ha0nkCxO4RBMazKLoC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
6bgBO5Snel2Gh_kXd0Xmm8LjLNKCwyLz-b8Jk0z_jYcC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
Z3f6vtVnTsLD_Az1zZlyh-fxZf5Ktiq_zQSrZNPudaEC
infra/tools/prpc/linux-riscv64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
ViGe-nRNBp3uX-4_yv-_L2bSWr3_PLtvExEm9ZCdbQUC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
GI-ec477TiZj_qKq8TnaTQHTd7mNg1HIa6sRsiKvT98C
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
L5auRzn91XQg-yZgF1rcKgDNNFoyXRgcrBcT8CyFPxwC
infra/tools/prpc/mac-arm64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
8BYgb-Cf84StNfoaBYY4ewI4U8N1db-xOY72PqXUuJkC
[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:bd3a982ae62b4820b71414b2340e86019a1fbd26
yyuRRM4hxE92TMqkRcb_kteWfro6Plt3u7opJFufS68C
infra/tools/prpc/windows-arm64
git_revision:bd3a982ae62b4820b71414b2340e86019a1fbd26
iFQvbmYSkL_IlmJkH5P21k3_-xKFRe4pshtZbH-k7dsC
infra/tools/rdb/linux-386
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
zEV08psUC7yb8dJPf-EzeCe3uyG5Sp5OVhp0gbmoU8UC
infra/tools/rdb/linux-amd64
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
wuoNKLLneVh_bNLadWLkke79BwE5fzNRfS0Oy7cQSwQC
infra/tools/rdb/linux-arm64
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
hINz_CzBLzP_9lU2I82nDlyPshaaEwt7QnnFBjb5a6cC
infra/tools/rdb/linux-armv6l
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
RZrEh2Wa5jQMLqEBFMBgY-tE58M4wDK2mbFgOxAC7ToC
infra/tools/rdb/linux-mips64
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
vJL54d6XxGHioEXmrpgJHJQwBNpdVRL0B6Xcis4uUf8C
infra/tools/rdb/linux-mips64le
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
ck_EDGM7aAA7Jm_A1Y4uPbKHNVlqKAiEtt_wubx6ctcC
infra/tools/rdb/linux-mipsle
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
g0X5FByGI4d2zn8KfWknINB3Y4M67Xca8A1hMEN3PjcC
infra/tools/rdb/linux-ppc64
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
lv1znYVLyWmYGPuRLd8DiLXrGpSid_1X9FZviou2xTEC
infra/tools/rdb/linux-ppc64le
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
FTSV4LGWIKjze02vkuMFyqDp3I_bJ8RRAokKR4eqonYC
infra/tools/rdb/linux-riscv64
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
dflroCOCfr6JBSI9nlI6b1RtyfyZ6ubqQAhJxBUxuFUC
infra/tools/rdb/linux-s390x
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
ZZZ2gp6kCApM5R6EQPJ-MbSt0F1hAeakOnhS4ILdru0C
infra/tools/rdb/mac-amd64
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
IEuCkPH378I9htx-vDlI5mRtgGpERjuDVbLGXMQY0ngC
infra/tools/rdb/mac-arm64
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
0ImziAHqv0_LEYlTcyTEClhZ-0pY6KnZg3vZ6Adxrd8C
infra/tools/rdb/windows-amd64
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
rTEMTYRZWEijL-ldHAK1C_7dcvjEBDdQ1_SM-UIE9ZoC
infra/tools/rdb/windows-arm64
git_revision:cbcb6b9a7008e31d33674b1ce0023db5d018b149
7Y6VS49n6vALQglPo7eNfNJ9KtTaN5VnFtzb2dIN_3oC