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

539 lines
18 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:e74dd94f00ae6be0c8272e438cd264e9817ad585
voocpVgmOy76SPLIKKwDw2ej54o11Fcc07-DWd5VovIC
infra/chromeperf/pinpoint/linux-amd64
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
HKGlT4YcCOdncPD41tx2qqw6YRDYGilaihiQJOzAADcC
infra/chromeperf/pinpoint/linux-arm64
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
KHKcbc4iB4IKqSn4chzpaAFhU5VWDVInA_jfkLIDB4wC
infra/chromeperf/pinpoint/linux-armv6l
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
aX4WBjiJ63OQB4c_GuelGO3d6dNLcT4JbhtX9BSRzu4C
infra/chromeperf/pinpoint/linux-mips64
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
nJQW96O5aLTPVgll3jj7Ee5bKg8IIdu166lKBO4wGSsC
infra/chromeperf/pinpoint/linux-mips64le
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
gRd2nXmMx9LnJYlQUmVefXxcZ_hHyDmrRdp9DRbgQSgC
infra/chromeperf/pinpoint/linux-mipsle
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
YQ9EEPvdfJiKa_yveB1nm8HZBca5O8ju4R1CUwv1JOQC
infra/chromeperf/pinpoint/linux-ppc64
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
r68g23vv-ffA2Xk55amTiyus6PCmWUiGwkDLuQaewMcC
infra/chromeperf/pinpoint/linux-ppc64le
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
fPn_8L5wmLag-uQzSw4LOA8E6qX4enaqFWnPkkLh9UwC
infra/chromeperf/pinpoint/linux-s390x
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
Xak5_zQXzVE9NJDp585FcjyTHTOxlKxcuFdeOCtAUXYC
infra/chromeperf/pinpoint/mac-amd64
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
ZSWKaAs8Ru90CssX1nvdYApCcFStjYYyXQ0_RpMG3pQC
infra/chromeperf/pinpoint/mac-arm64
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
ziY_WsU6yVoboLF8mxp6E2bUSfwEuOfGqRZDqWj6-HgC
infra/chromeperf/pinpoint/windows-amd64
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
ipwQzoM1wJau6T_KOCoUqBt7VFNvyrs21l1s16k9qLQC
infra/chromeperf/pinpoint/windows-arm64
git_revision:e74dd94f00ae6be0c8272e438cd264e9817ad585
peMmYTAzWTqkVIGb7qSLKrW6TTat4K5SMnmfBMqWr74C
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:3435fce1653aa1d611c2834901561be7e6ccfab0
6EmVw4-ll63s6BZJ_IqUnc4e0EhMfmuhZWlym7rNU34C
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:3435fce1653aa1d611c2834901561be7e6ccfab0
Q8Oi9o1glHbQ0OiNLg0j0CD78so89daZ3a3jhTcwahYC
infra/goma/client/mac-arm64
git_revision:3435fce1653aa1d611c2834901561be7e6ccfab0
8A_rsX8IeV_S8J6Hn8zfwWab7vLsVjbsujR0vuDNxxcC
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:3435fce1653aa1d611c2834901561be7e6ccfab0
T6Xs4ivcOHmuFd22Lf4mjDNhiZARmLvjK7P1RN2Q35kC
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.101.0.6210d0d-gomaip
QIkkdyLfCLyZpWdJoTC8EgbCT7QcUuClhWw4rL_wcuwC
infra/tools/bb/linux-386
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
1po5AXHrqwkB6b2FYbzqUYDr7sf-7o0209XtSDiiuOAC
infra/tools/bb/linux-amd64
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
vrRipWHKM5Sit7gQqDDeh4Oj-YBKFsUsBwg6-C-4TloC
infra/tools/bb/linux-arm64
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
3qUL8-0b8RLscZ0sC6ugFM13-xlYUZTlMqkm69CDtvAC
infra/tools/bb/linux-armv6l
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
fRLNdi2ZScJa8GamwCI47sIgCjApj5ORmVavhPiMh_0C
infra/tools/bb/linux-mips64
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
LZj5JYxD2_hgXAaqL4p4BJd7AIgQgRHAVk8NyktPs3AC
infra/tools/bb/linux-mips64le
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
LhBOTm042IY4t3-dmzvRPmIdG1am93Ew0idzxp3ARM0C
infra/tools/bb/linux-mipsle
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
vjWHMneMr7zvKfsk1-z5ySatcJKnw7hskFqbwam0cUUC
infra/tools/bb/linux-ppc64
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
UHY8-gag4_djxs8nqmesM591dAw0kLhiaPhJndLzuf0C
infra/tools/bb/linux-ppc64le
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
ERKGDCv4IIECJLpY1dbodq7Oa5eIg2HgS6dntRfSlWAC
infra/tools/bb/linux-s390x
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
tqqmgaiGN47SZrPrwegZTqkEXgIDFHJpC8C9e8g_5vMC
infra/tools/bb/mac-amd64
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
ojD07FK6tipK2_S9YpFcSwrPxh13LOQiOubOnZR_WCsC
infra/tools/bb/mac-arm64
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
Hx76JySkZu3Tsv0KJ87-f9suRnsKbMbE9z9W91Jg_EAC
infra/tools/bb/windows-amd64
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
SW6ncPyG6lE9aay4kKaKzzhPgOhhqmIP-tWykvhnEeAC
infra/tools/bb/windows-arm64
git_revision:b083b65e849f49f5792aae39e04ce12530b48ba3
TdjHejl4U5WDwkv502s8YPIo7YYZXkCSQSyLufXymvEC
infra/tools/dirmd/linux-386
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
w2idIE9Y_-0aZyA51pMYFiZrJJQy_0669l_diLMLcPEC
infra/tools/dirmd/linux-amd64
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
pbNOz7TUtGKt3W_ULWBpkUjTOvwum346CrKicGE4XTUC
infra/tools/dirmd/linux-arm64
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
JKzTQIcsm_UzLbXXvga0HZ2tH_q1tZhZtW8ZNprpLMwC
infra/tools/dirmd/linux-armv6l
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
0kBd-WW4APbZKKCjVlmdokzaGglmPMzz1458M64CLYkC
infra/tools/dirmd/linux-mips64
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
fp_h0G3uKwJ-_n0II0aspHVzi4xuGPXKJ7Cqr6XVHTQC
infra/tools/dirmd/linux-mips64le
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
z5ACNSmSs6F9rP7gsxiDd71rHIGmyGygkuyqgDOc6egC
infra/tools/dirmd/linux-mipsle
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
kD5UkpxcIPhRpJb5UkqRyn_mWuil6FUPXyNJ2vGBmREC
infra/tools/dirmd/linux-ppc64
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
e6hVWiqTRL2eIWFOH3JbF9ibR8UyH8sHncofBG6kjWYC
infra/tools/dirmd/linux-ppc64le
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
J9BeINhVISFz4UXyKiVh3zWQHmSR8PlNSsP6BmCzEDkC
infra/tools/dirmd/linux-s390x
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
PiAMR9Hh8jS14zlDbi6gut3evAFbIN3yn32N3asqc5UC
infra/tools/dirmd/mac-amd64
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
wJFrCrcW6vGROGf8Vf9_AIMB1Tshzv_4kTHFryMQs-cC
infra/tools/dirmd/mac-arm64
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
XO4N9glA18B2J3DOne4IE6POcwA9Fp88gO77axn8hFAC
infra/tools/dirmd/windows-amd64
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
6ygD207BD00j60XrRNC12iDmIt4AI7e31GPMpFdZoEUC
infra/tools/dirmd/windows-arm64
git_revision:84ac80ec64abf5388e9e4cbd4a71b5e0d73789df
pcr1RZDyg3SVhvpOCaQ1ZZ4kHmPdT1J6yb4uZ2ZSwpUC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
wK-qkJG6wZZJW73O5B5W-qmldoE-f7Rv9lGlvLrVJ-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-amd64
git_revision:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
abG7bRd8jOHcCgZn4DwZDaoIXiz3PdAtjLNEI3I1sKsC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
9TkIPLzpRXYfkL1cOKeUGV3bkAS5FhIZQD4vhKewaUIC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
fWMNOuVRftg6IJK3qWtP3REDap8IlEs8GeGzBxQiJ90C
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
OaZi-l-Z7qvYLOt2uiCbHnAeVkIAafgV8aqj6UZS3aoC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
-AJw5QZYWISOXzLXXoat24zuaRqqU9WCbZB59jJ_bIYC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
SJD1uKof-lwqkXcVCkCXGnGdtf87GtNDJOOQ8uOFBOgC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
V-wne2OFe5ATyx4XrJzHiVNHShrf_TrYsj2C3C2feyMC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
_ERajsHeFxNuzzfCogzscveoKzqZ9ciC4HGwVzcgyHIC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
1goLBy_OW_PoIeoNvBvVAUArrsYVVdgWjVrY_eRUDXwC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
G6kSrnx6wwhg06tJz35FFYBVLd8-CzqAP_5gB1z7xHcC
infra/tools/luci-auth/mac-arm64
git_revision:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
noM_lnXNlBDeEeFSRQPCVK9rRSfdLjlm0fdJIReO-a8C
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
AX9y63R0nxVRrX24LSdDcXAugxHzgm9QG5knb6SKZ7gC
infra/tools/luci-auth/windows-arm64
git_revision:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
lVkrcu4Q8BEII4jXyQaMktfcYDNPEzlP9C39M3q8FBwC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
jToHM9WoQcLAJd5C_Wg6tE8pP9zGcke6OMw0DIrHAB8C
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
vAKR3FdYAuzWChvsSU8YWFvUn4kW0LbZEwzLlgBUkIgC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
Vd63abkSwqejo_5N8qg-q3gY6qNM40PEYCmJNcKsUusC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
aoshKKAvW-i0ESmauDlHqXBe5y63w9GDheR3ue79TV4C
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
EAEgNmQyz79IEGB4LtlGU9SR4fO8VG8ZTRYdAbOoQXQC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
L2zeWurH_2XjCDa8JU7gzQbz76qSWCV-MkBM4KRc_xgC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
Z6lJxxmFd1yB-xanqlgN2W7CVH9-B_Ey46ln869WHLMC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
KveTfou0GCAqCGOTjOOY0umSp4QdDs6PseVAAb090j0C
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
KBD6lzPTeQvF4be5xmaDEOuR_QqshEOfv4AfuJHkD-IC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
z4oy_Er7zs7NTIUWvt94kybn3k8tfyzV94hSOhZujbMC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
7YwrmRPnnkILamRZEdTmGdYYsHqexYiz_CuU4BM0_fsC
infra/tools/luci/led/mac-arm64
git_revision:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
P1MNkYLyjrACtd95daSTD_uMNhGkfhiaFfjAtU0f2vUC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
8OU29EdrDvPLgXDRAYLuknN6xUfZoGZeyzdCTrI1l8kC
infra/tools/luci/led/windows-arm64
git_revision:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
sK9o5fbGnTnMGrZM4uP6QBcmFRhJwGXrzuvPqjqjAJcC
[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:8afdc8e6f4cf12025a391263869fb4ff84bab810
2nAvAIWekwRArCqCrwavv-7cs93NX2CuAh_pkStTpNUC
infra/tools/luci/lucicfg/linux-amd64
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
WXyIWBPzY4jGDhe7a0FZu-DupO40tAw-nMtqVp8tCw4C
infra/tools/luci/lucicfg/linux-arm64
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
bRDYWp6_WXEv-hM47Dv7cfmUuhWiU_1mHXBLfR84ELAC
infra/tools/luci/lucicfg/linux-armv6l
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
dGOSCXQPoYzFR3pUBq6ed-bi9_S7FE37D55GrLQsacEC
infra/tools/luci/lucicfg/linux-mips64
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
MYcXQInpeXNo-xCE4zLFZGdauKZpVETri9JYwqCOBKYC
infra/tools/luci/lucicfg/linux-mips64le
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
_KSqJAc0_bRpWb8BVpuTTTMa-SyTPqwGRtc_SoB3X9MC
infra/tools/luci/lucicfg/linux-mipsle
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
eX7aB3xcEi-iIkg7fu87t021YzKlmd4bEFRjx54jE9wC
infra/tools/luci/lucicfg/linux-ppc64
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
5-H3k-cO8CboZ-4xLz8QOHj_GzYNQRTyJubMesIudqkC
infra/tools/luci/lucicfg/linux-ppc64le
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
mHf6TFz1RRbvZdZTquvnv1MFfRs2S8kjEP074fAP6noC
infra/tools/luci/lucicfg/linux-s390x
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
rS4HhlhXeTJOa2YJOMBOQT7ttCW4WFFOqo81aB0rqU8C
infra/tools/luci/lucicfg/mac-amd64
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
8a5JIM8zV5kKR68umItuBrKxyOYgQJTHP07j7nI1n0UC
infra/tools/luci/lucicfg/mac-arm64
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
vczHVY-2VbcmoU9k_p1qg2WYX-g_gxmYLwkYqwkYc30C
infra/tools/luci/lucicfg/windows-amd64
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
5pLfojImQAax8D9dqGVfMpH7NjTPiIIHF87ZTnVGY2gC
infra/tools/luci/lucicfg/windows-arm64
git_revision:8afdc8e6f4cf12025a391263869fb4ff84bab810
h2HD4no-PjUz7qcRkbrn2q6n0ReAsOWjHiZUREPV20EC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-386
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
eGwM15U21ZJfAQUr3fwhBXJjbs0C9R5PhQ2s7ffJ5x4C
[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
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
9yAXv0KsU9JAgagYQxkjWkU_YUDsDJpdQ4Rktg-EJDoC
[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
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
caLUJKwXkeJqNbXe8VrUaJapyclM4Pi8UqrVMDYRvqMC
[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
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
4DqSKhlfFqV13-5gC0ocY9p6ywv-cJiL2NilLkppLiIC
[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
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
N6eu72sj__hX71cv_zxtnmskb1JPT3H5peTA0A4hWQ4C
[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
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
2fVbrtfqruPr0fCu6WzUd6F0ZzZOAeSewpvkvK9qvl0C
[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
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
44Pd9YZvAOGgXkir4GV_3nfWF6DFFOx91y7hrdeKCpgC
[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
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
2bF-o3-L4WWbUHR6SvsVUAq6X8ZcQvT0GD762sM2CYEC
[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
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
5eTfzvKq0RH3XgWLuhKPyVFGwbYi3fWogKENRq2wx9MC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-s390x
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
y8M08KKGmPcQtUc9O3ISZAvG0cXSDvevJrk59xhC9j0C
[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
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
Jdog2fhqcbdX7c8uZTwC0ED0Z6Se8-Qj0IKZzzfkTqcC
infra/tools/luci/vpython/mac-arm64
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
5od2TokCifZKqqmc-6P-rVJHCbq9-3ogCbY8M3SRFooC
[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
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
nRUaJj85Xfp87bEW6FjXOde90sf-KhSbhL0b08ZDXU8C
infra/tools/luci/vpython/windows-arm64
Revert "New vpython to depot_tools" This reverts commit 43083529de5802a83f53f1d53d7f5f9615999996. Reason for revert: crbug.com/1470122 Original change's description: > New vpython to depot_tools > > This is a reland of https://crrev.com/c/4653897 > Fixed the issue for cipd wrapper. Now all environment variables should > be perserved when invoking cipd: https://crrev.com/c/4669637 > > 1. virtualenv field in the spec is ignored. > 2. --vpython-tool removed support for delete and help subcommands. > 3. --vpython-tool installed removed support for naming venv. > 4. removed support for -vpython-interpreter. > 5. removed support for searching interpreters in host PATH. > 6. python 2.7 is available only if the binary is invoked as `vpython`. > 7. fixed a bug that passes invalid vpython arguments to the script, > which may be silently ignored. > 8. python_version in the vpython_spec must specify a minor version > (python_version: "3" is not valid anymore). > 9. vpython now requires the cipd binary to be present in PATH, which is > true already when using Swarming or depot_tools. > > Also updates the LUCI_OWNERS to add peep-software-deploy team. > > Bug:1415212 > Change-Id: Ie541a2a60bef829a976a13db9a6732b406c4d878 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4719827 > Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> > Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Bug: 1415212 Change-Id: I6ca32066acd977a293f8b8f42697c383cc2a93fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/4751179 Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Chenlin Fan <fancl@chromium.org>
2 years ago
git_revision:7db81fdd219325d5d11fdaf56357ec28c26fffb3
AHTqVMdkiBvkdKKoeo4Ib8z-ACkfIgRuKFos3WADrlAC
[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:59ddedfe3849abf560cbe0b41bb8e431041cd2bb
P-QZDNa0TVwuVwDgSBuJig9baBK1aqZ6QKqspN3KLEoC
[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:59ddedfe3849abf560cbe0b41bb8e431041cd2bb
u9Z_N-UyoWSSmFTMfWjKmkTMQbFw-LwMgvAGFj1yGHgC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
I4hb3OsZfkhwNgfmRbc8mjb6Y7OLjdrhmleN4Js3gpgC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
eWrhG4AyvG7uabtZJTRVZVEXNgctS_qkz5QLHuIbcywC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
RH7U2Y_ku0I3obRLh8jSqnaJGMik_CjWPCF5FvOlmAQC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
UQJoPMTFQZuj0e-kxTf7yPIhIudYceShrVKv_-T6FWEC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
3Gpjanf3yuC_CBSBrsQke8sia9R8r0qF001tQmYopTEC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
gUtVqVqL-CQrD9c9W_rOksNDMqShImnUZWzNaB_FVegC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
rD9DSoXtnBsacUK9EsIpjPOnrId4nfGayVVsKolyPaYC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
wHuhPa3CsbnrFHA3nvb_wlz9Wh6oOrzOg-j1154Yt5EC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
psgkfBIZPbwsWljqSKuUuRlc5hYYHfPIpgUlLWXj1UQC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
630v0D7jfQg1NpvkgHgO76LAPpVC7sfHeOj7g7J16Z0C
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
u1LsDRxpsJkQ-Wkg-jgywzvfIFifCTmqA-xEjB-m1iAC
infra/tools/prpc/mac-arm64
git_revision:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
UE10VYFCL_5zkHA6K1Cowzqt3P6G5Qx3KypE_IbkKOMC
[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:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
UE-LuuU6e4ZLsD0niWn1rOud8w4OIMwDnIX_s3id-5AC
infra/tools/prpc/windows-arm64
git_revision:6e9be28a4c4e3a804f400dc6c2ed08b866f0a38b
7KTsAKpNk_UH2oQhHwZYHpF0OpvSoipAZY9qRnMk4AEC
infra/tools/rdb/linux-386
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
_Y2m1kyroqbtzb1D2ukTctJmRY_n-akf8iReh8yI68sC
infra/tools/rdb/linux-amd64
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
FMiYxXxW7e80Q05063_1aRUZTmRTN8ZDTYOZIpIoD5EC
infra/tools/rdb/linux-arm64
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
74Ht7j3VFJFDBxP1ThgAyWaLvyfGyUvZuzg8Sbq7p6wC
infra/tools/rdb/linux-armv6l
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
LE4Xylu2olxgJBySC2TK6vCDyRxupc3pVLZWkY7ERU8C
infra/tools/rdb/linux-mips64
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
iPGsA_vRmxBBjc9gdnhEW0yMPpGx7xwWtEu-RRKFfCkC
infra/tools/rdb/linux-mips64le
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
jKzygzizl-pR2M0Iax_6JqnHqv3XtpM7UMlcrYdJIYcC
infra/tools/rdb/linux-mipsle
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
7kllOu390y5OQ97_ML9z04XFeQ_y2FuztoZPHjF67QoC
infra/tools/rdb/linux-ppc64
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
zCOOAsFLyn1_yCzbuoUxE5kO89dhHHbl9VoexHmvtcEC
infra/tools/rdb/linux-ppc64le
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
6srU3OC6m2fS29qxrixWdogYDZ0lX0-adIvw8Dw-cPcC
infra/tools/rdb/linux-s390x
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
Yx71IMXKheXLtQojfl8rA24WZlhEU73hFQS7BH-w3bAC
infra/tools/rdb/mac-amd64
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
K18bDmcE5Zr7pBY5dtNA6rP3zhR_jpIP4_9RrbkRgoMC
infra/tools/rdb/mac-arm64
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
6TYpzQz27_jMlMs5ghtB3NmhWwhw2uREEUt2UIdZBxMC
infra/tools/rdb/windows-amd64
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
XQdH4Il3e8NabeLSgwb0VUL0LLRYZIJIkukPpb_ygJ0C
infra/tools/rdb/windows-arm64
git_revision:2ed07b3775e71f9a84743290144c52f43d0899ec
RueLDru60JHz-Dl6KipnoanPwUEwBAtUz7eF7SSEPbAC