aiden
/
depot_tools
mirror of https://chromium.googlesource.com/chromium/tools/depot_tools
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
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.
main
chrome/4147
chrome/3987
chrome/3865
chrome/3904
infra/config
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'b58d4bda63'
${ noResults }
depot_tools/cipd_manifest.versions

215 lines
7.1 KiB
Plaintext
Raw Normal View History Unescape Escape

[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.
infra/tools/luci-auth/linux-386
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
xAg3WX2ex3ULkoVUsbr6B65nuYnpWaFNu6BO6HhQ0sgC
infra/tools/luci-auth/linux-amd64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
cexxITLLto0E5R-VwXpZWQUq1mXCXXGjGbew22M66cMC
infra/tools/luci-auth/linux-arm64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
SZ5EOimriMpRBY4fGC_Rp3TV41sbgHzw9gjZYFmgV6UC
infra/tools/luci-auth/linux-armv6l
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
oCC_oVAcUUKscPFq_kFjWxXYIVzjG-r0_DV_n3EohRsC
infra/tools/luci-auth/linux-mips64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
_-5uoJFORdex2t1QyS_ihDb7lFQAz4DdROaPatVoI1IC
infra/tools/luci-auth/linux-mips64le
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
bT5siMU35bfMAtjaUbQpg0o5EVi70sF9jNte-593-TcC
infra/tools/luci-auth/linux-mipsle
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
AQ7Ka00m0aVQ_Gspqfj-PeNM4j2YhxYypnVmeDEA9UQC
infra/tools/luci-auth/linux-ppc64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
ELLeZLgltcdkFDgwRKKmp9WMo8buIsL3NdkWxtGQoH4C
infra/tools/luci-auth/linux-ppc64le
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
wlj-VEzFtvkweSFQfq8HbyY0GJI3EJFMzlpKhHOzrcEC
infra/tools/luci-auth/linux-s390x
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
_hVxrjyTUEQaqoe5ckdj4bNHZxbl6aC5whk8bgulzP8C
infra/tools/luci-auth/mac-amd64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
PloatKD-3d2iygSAaYo9jT6IO2C-wZvEqcto1vndsMoC
infra/tools/luci-auth/windows-386
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
FNfv1qwbmJiKVnFezV75UpPm_UdPcMHEnY253OdijTEC
infra/tools/luci-auth/windows-amd64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
1Y3Hk3hG0yhvLiQc1_HxEr8CtFJTjv92JvyvxIpiiGIC
infra/tools/luci/led/linux-386
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
nLvnRuALs_P4plwCaBa6bTXHjNZF2BCiqTca0KZqJ90C
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
8xpJAIBSFq8Q8I24lOnMtq5QmOgx8pzk5ZE1FrFAb-kC
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
hS8-_4Xw-g-X0Bvjb6h8hIBsIeGeCu9feWKBnY1DoAoC
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
fm2eh_qNuJfGFvu80-n_TCYgE2ch2J9hPDGsuLBXLyQC
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
PRKNom3Y8yBNIilWUC138bBUaOVDZG6pa9VFo9ZFmSIC
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
_n2ArUvXJBLHFDuRAnPSD0EtNyCZsAoUtE6TQLUqmLkC
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
S_44VV8unNN5_bQYQ3snvgo7fjUBAh8exGEHX207C2cC
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
iECYGKOxM5cgxPz1Q6iEZk2H2g0UxUIPf4OYL2GJ9NIC
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
xv6JiRcSUG8kruZ2JWl49u28EuUTfge1D15mQS2xVN0C
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
Hes6M-tX6IsijNPnMnWgUfXg17aLc1ivyXjN8or4pTwC
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
qaCFh7-237bBbhZ7KfWMpZCaLu4q11omBkp72pTlKBoC
[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-386
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
c_yE-kFSmEqOcec12GWxBBwO4iKIC3XwxhAwF82ezSIC
[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
[led] Update led to latest version. Fixes issue with bogus secret bytes being included when running `led get-build`. The server would return "<REDACTED>".encode("base64"), and led would pass this along to the task, which would fail to decode it as a proto. R=nodir@chromium.org, vadimsh@chromium.org Change-Id: Ie8b33a2dc1f05ddb163465d72ea461f9e6833363 Reviewed-on: https://chromium-review.googlesource.com/c/1340504 Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Nodir Turakulov <nodir@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:522debceb9aeba7dbce7f811687a640656d4e8cd
ouYuUP-NyULtT9q3XdEMe9bg0Z5chYDGZfhZ2BzGhucC
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
_XghQLpCauYSoYVMyCG2QsGAWPFR40gAI1d6ViNicWYC
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
ucaOciwAE9aweCUDOrmSvyiwrjmbywuB0NzAGUXIHjAC
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
OWIN1DWx9G0qqKXgYVlMkM9H-VU_VQYA0vocEFcCuRcC
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
Rg6IkKVeR09IY0yGBlhuK3jf3YnglPbpThfR6mqq-rwC
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
IGAm1cfhi1VrOG7K_cXPOxM4fJWjcMJS6q2jSgxm1d8C
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
Rjn4KEBFquH55jhaZszLfAw1V8XlqKh-PLy-Yqv44e4C
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
UDwfezAV19wjJgC9CMQwJa5AlI8ZybWBes_xJm-e5iAC
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
liWMYGNyzC-jv-bdglNhPqvY0wSD0U4Fl14sT39ax-MC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-ppc64le
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
-MmyGCT3WMS27V9mWCrGMDeog3-cYkY579W5xOhCFLAC
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
3iI0Un8ppWBfFBQrqIT08SXSYGxMavYmvIuaA4vZWVEC
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
yhDQeJa8hj64DkPAcLKVNQmNTgYsirl5_wvmnHvOz9cC
[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-386
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
YAQ_TOR4UzXv7K7imbeqe0hexj0EPUjtz21NvYCDBVIC
[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
[vpython] Re-roll to pick up user differentiation of cached envs Now with correct error handling. R=nodir@chromium.org, vadimsh@chromium.org Bug: 869227 Change-Id: I961fd80209c9d9988e9d03016b7c0bd253c6cdfb Reviewed-on: https://chromium-review.googlesource.com/c/1347249 Commit-Queue: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Auto-Submit: Robbie Iannucci <iannucci@chromium.org> Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
6 years ago
git_revision:96f81e737868d43124b4661cf1c325296ca04944
EUJh_9q20TnqjtRumVX8fcDubyBDjOpzAl-sJSKGN2EC
[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:9a931a5307c46b16b1c12e01e8239d4a73830b89
vNT-t_YkKEmj1dxZngt1gE8wkNrFxDkaI4qJlrmb6mUC
infra/tools/prpc/linux-386
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
sgVa6Bqe47iNq_DUsB-lSCfxlou8r4uerxNg4umTO2EC
infra/tools/prpc/linux-amd64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
qIKuSNcuWDXDxEsV459Y9O38lFmjI0zSFf9fv8bCZ1cC
infra/tools/prpc/linux-arm64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
y1ZfMndSGAU0lvne0JdMz5lAmuPht63WBlTvOxPZgX0C
infra/tools/prpc/linux-armv6l
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
Uz6gU2q_O1scRPoXrRwrrS680hJKkzoUSeaWGNBBuscC
infra/tools/prpc/linux-mips64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
M1-JZBfVj4yGaBKDZDXtVs7zL1ZUKmTU--A1iHcfIl8C
infra/tools/prpc/linux-mips64le
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
nvFzHditASTC_uC5mpTBVJW8lNOr59xsOdZwMsDz-ssC
infra/tools/prpc/linux-mipsle
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
AGR2Viao8FsoJrhFN2FFT4JT-0owJmsnK3Co_GNh2lAC
infra/tools/prpc/linux-ppc64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
UDHoL3Ay_TtgKL8i0gH8ct745FcejLx79OKEo-jdl34C
infra/tools/prpc/linux-ppc64le
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
10EhRfS4lfa8Yzr5OuSstYJTyHMxBlbegU7FRYSE580C
infra/tools/prpc/linux-s390x
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
ZCOvdJxiARghbyT99Cyk5QYRghgTzoXL03KG9UxILtoC
infra/tools/prpc/mac-amd64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
0O-YV-VdtsIyIvEcBluv6fW_qa_ZZ5t6_iod8vYcuhAC
infra/tools/prpc/windows-386
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
MbSykhR59B-iwL26ZhQfgYv8YgRJGA1179EDOICqrkIC
infra/tools/prpc/windows-amd64
git_revision:9a931a5307c46b16b1c12e01e8239d4a73830b89
zHI_Z_f3YwKQPBNWMCPhmiqyxt_vROHZVCZjHKYRTvIC