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

323 lines
11 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/tools/bb/linux-386
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
Ebjauqd0o3KlNnOcHxG_IP-uZsOaRDndybE6ylUF4PIC
infra/tools/bb/linux-amd64
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
eSYAlDJHtdOBQ0L2ItwQTg110ITohUsK4dl81b2bgiwC
infra/tools/bb/linux-arm64
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
6kjGLZJiW2fuJOOrK9dnH9jaeV-ZKzdrexAvEIfXF5AC
infra/tools/bb/linux-armv6l
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
yFXOGQR3AKpjQ2oxUybpeRPxwGn22480LR_Rbx6i9zYC
infra/tools/bb/linux-mips64
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
dRcfv9O1g4-XWYr2wdmL5m1_kHm_7-FaHNZI91ksodkC
infra/tools/bb/linux-mips64le
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
DTkMKQOnE8C4r0xH9KVxFsvb5NB6JS5o6i-CdXPAf8UC
infra/tools/bb/linux-mipsle
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
6oJZm1xMht-W1aqbxT2o59nQvGmJcoK_P82KHVGuP7kC
infra/tools/bb/linux-ppc64
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
4vPKBYOZeVUX-wQv79fOc5hI3BsPkS7pYo2RmJX9AnMC
infra/tools/bb/linux-ppc64le
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
RLeMwX5xQXSlAyMNqpeLbu_hK7Ho_Umn0aE4fe_hZ1EC
infra/tools/bb/linux-s390x
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
_CHImfxmnD3BXKNDXdvD_S3CEIihrsMPxsg2ae-mGwAC
infra/tools/bb/mac-amd64
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
JYPUpVJfYLHlVRAdxEXQuLAe0oSLbsh6fGzksGnWrIEC
infra/tools/bb/windows-386
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
5mpNAc7dYz5DOC-mYubACbyrqM8DnIpCMPle4XT9Rp0C
infra/tools/bb/windows-amd64
git_revision:bdbeaf7b6f457238c69f328bfc7684fc1f2a79e6
PMEgvSLvoPU8ztuXaFqt0I1cm1t5zoDWuRDspF77il0C
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
8TWSqbfcomDrxK72OV-nPlCUsb58EiGmWPI7Ml3C1j4C
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
nVALr-QAQcGQzbeduXLm18hqyxFmi2NxfJ--3iW7BhUC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
hV3ksc0ub0GrxOx8C4hMOfjswtKrdHYl8Svt6_1RrDgC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
Qq9BPtwG3VKRHHwEwI2-8W8nPeyLeVL1Nvhw2uTG50gC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
Arr-nYTrW89jp-E6g1NXpkZ2Er8q4CJm7A1Z6FnYcJIC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
j65WEvX_eRsHFUZ8zAQDZF2eadCfdCp8RYgHQOm2_a0C
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
QXLayUV_TvsPU2ak8YFFH9yCN3y45HlYr_I_nN69JK4C
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
CrEGeZSEp8erFoF07WfO17_XLIgKGiCBr1HSsVpRGa0C
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
0rogC4GEIKSXnV8Na5fKIrDe8fsRF8Q4yTMNqdGMVCEC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
3el1lBm8KsCamV8r8H2e052zg-Yf6t4pZdUzuyWRm44C
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
9SZu6I4X6qu0mqPhjD2U7YmLk1SkPPh4x5hUhvIHTdUC
[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-386
git_revision:edd5644be66d37cdf82978efb0e5d6504d0d552f
l3cXhvcusi9ypW-29WeabxvkEVjQ6p1Xwc80VfLTqNwC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
GBs8p3OBQPPVvztd0oS5qFhvEy5JVvPZFnbod0DZ-FAC
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
gDmfjgb3BEflqEhO_krNIX8rHyHtYOG_646eyxJnkAgC
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
JfbZ84-030THccrx1bt76ttYLQdlGelcqbWRCWQhosIC
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
y-XGlsH7eLgByh1-a3FVavt1WWDxX3iISEPHhr3WoWcC
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
zhxsuiptydyslnQS1lNzB3jB1MkEZO_QVFaY90WSNOkC
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
xlU29rpn0g7UfFk7ApqwCL1y7-8mA-lnsRjvW_x4e30C
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
GMr1ZNJXU7yGJeSDqTpjH9yHVgzzQedLQkJfOY9NfUoC
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
B5dmyOF2wpvsea4n7-lVeATe7uFYoERaD68qJkoKkSIC
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
Pohe6tmDwK4dKz1mXYMsm6qkzWZnfq4tpNK-qZ1w5BEC
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
zO3a5ZBM1B0uzNOWwRRYUe5C4St3AeuygH-sd5fxz5sC
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
g8zcyLIRAUKaSx1XyHj5wF7lc2FaIhLHjfL6u-ywsfUC
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
LEZlk8BQ9q6ScJjVXRXBHTY9dMlYqmmvwJgH_L8ciycC
[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
git_revision:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
33J-_RFWits3USHI4J65qENsjb0GO2NRt1WZNjnEPM8C
[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:4799a3f4989e43e0dae5c35dfe5ce76cbdbb6125
Lw3JGnXTz-SLluP-TO8fXuj8nSuHAbuHshy_jjQs0bsC
[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:79dd13c2262d61758111e6d7205e44d94ef47fbc
h54dt8IuHmagHu6SKEcdtChEawFBIm8m40PzUaITUB8C
infra/tools/luci/lucicfg/linux-amd64
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
-dT0kf2C5Oxk5cHF7m-uRc-Kr8e3Cg2ioR88UxPz5_cC
infra/tools/luci/lucicfg/linux-arm64
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
mtPXE6YLdG73c7U6zbPPxogruMMbKW5etUXpeyFgNL0C
infra/tools/luci/lucicfg/linux-armv6l
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
HvXuZe0vKaig9ehdydXhSTDnNh-_6r97auAeFNvu9_4C
infra/tools/luci/lucicfg/linux-mips64
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
w9ff_H5rWCX2-Uno96mhh6dVYpRZdtCZle6oMDARN4YC
infra/tools/luci/lucicfg/linux-mips64le
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
knTtEQ_i1fGJL1hGbftDZpBeZGmuP91A-MFgz8biXMoC
infra/tools/luci/lucicfg/linux-mipsle
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
_9bhrh2KWWrUNeKqT7xTMwnpPfPe1D0XyAsx-arK-IwC
infra/tools/luci/lucicfg/linux-ppc64
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
F_4hblZQRoIqidZK4K10EG71YBJoPZAIK8I2GRNGsokC
infra/tools/luci/lucicfg/linux-ppc64le
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
gL-mbKCHAGQKEAv9739NehFI7w-slgNPBSD_aiGSvoUC
infra/tools/luci/lucicfg/linux-s390x
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
nEVuvcMN2R9fZjrq1X2sFlKhHO9OgU3OC0Br4Fr8AqoC
infra/tools/luci/lucicfg/mac-amd64
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
BuzAGgYM-meRlOMSVeJFNsjHDR0AeUaI3aT2D8-a6X0C
infra/tools/luci/lucicfg/windows-386
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
O9BhFKn1SXlpsuDlnVswYFQNlm4q5-_ZmCUatIh8bVYC
infra/tools/luci/lucicfg/windows-amd64
git_revision:79dd13c2262d61758111e6d7205e44d94ef47fbc
plKp8PGs-lTnocE2Xrm9sHaw4PfV9Y70yn4OZSULs30C
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-386
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
_QFAQsuYdC5gxkewm3kyn7uVX2d3yN3uwhHsv5Sfhz8C
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-amd64
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
XYVyPEMXa9mujkJAm9zVtrCZjwH8HeCWQ2V-rsX4cfsC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-arm64
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
2czDjMzZ8CO_wUkQSbUzVYpIIlImwxHosMuM3_ElGq4C
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-armv6l
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
wnNC62KiTEf9hAUlvgyplG90JzGsckuu5nIjFv-1LOIC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-mips64
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
HGKehSHP23TdXYrTXd4ZvVO9VC1wTR5BWsvCotcTNdMC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-mips64le
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
_wKtGHiVJboEczc_CzfizgR6wNr6EBwE8RSGbbYC3lUC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-mipsle
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
ZcjUyhapefCJDK44Dg2ZtD8S3n2uYJ44WXc0W8G2370C
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-ppc64
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
TFVy10cgzf2KhtuEIiCQ7VmJaz_zuPG1hTCjY1vtt8MC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-ppc64le
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
rgnykdUeIV3k5WWZguGxqbxlliyIKgCraPv7UjL9KOAC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/linux-s390x
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
2E88PYFZqBas7fDQwh44elysDKrUVJ0XwG8xEgeDnsoC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/mac-amd64
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
o4zQ8L5AxEHiBkrHkzaC_COnp3Jgcf1zDvTCNSqaDN8C
[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
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
OykuT4GhjAkfXOULX9orW_pQpPqXmII9KxSXlX9W1kcC
[cipd] Pin hashes of CIPD packages. Together with already committed cipd_client_version.digests file, this cryptographically binds contents of CIPD packages used by depot_tools with depot_tool's git revision (assuming the CIPD client pinned by cipd_client_version.digests is trusted too, which can presumably be verified when it is being pinned). This holds true even if the CIPD backend is compromised. The worst that can happen is a denial of service (e.g. if the backend refuses to serve packages at all). If a bad backend tries to serve a malicious (unexpected) CIPD client, 'cipd' bootstrap script (and its powershell counterpart) will detect a mismatch between SHA256 of the fetched binary and what's specified in cipd_client_version.digests, and will refuse to run the untrusted binary. Similarly, if the bad backend tries to serve some other unexpected package (in place of a package specified in cipd_manifest.txt), the CIPD client (already verified and trusted as this point) will detect a mismatch between what was fetched and what's pinned in cipd_manifest.versions, and will refuse to install untrusted files. cipd_manifest.versions was generated from cipd_manifest.txt by: $ cipd ensure-file-resolve -ensure-file cipd_manifest.txt This will have to be rerun each time cipd_manifest.txt is updated. There's a presubmit check that verifies *.versions file is up-to-date (it's part of 'cipd ensure-file-verify'). BUG=870166 R=nodir@chromium.org, iannucci@chromium.org, tandrii@chromium.org Change-Id: I25314adf0a9b05c69cd16e75aff01dbc79c87aa5 Reviewed-on: https://chromium-review.googlesource.com/1227435 Commit-Queue: Vadim Shtayura <vadimsh@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
7 years ago
infra/tools/luci/vpython/windows-amd64
git_revision:10e1d79ac9ced2b819221e06535f457093b2a14c
b_XN8vxix13LonRV_o_NNIvr00l5poh41_LRoUsyycEC
[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:9a1adc55bf4a1173784da3ba2f8cb06421606748
RiLbLddPgcxbnzu6nBOHc6RWmP6zO6vWQtWr9zoW2qQC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
tGUz4jW0Ade3imPLEFKRw_P4bjAS7bv5m2PlzVQ6jz8C
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
pExQS2vSbmaeBkZkdOavcI4eVXfEvox789FgQBPHsxIC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
saOhcc1VfDbTUCoKjK8pySKKM7Iey3PBMnX-oo4Uu6UC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
mgp4kRNoetXPvq-H537SBuI2-UbuX7DTEZoYvRhKmCsC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
7ZJBF9a0cErmn8KtWNWr_sZzirXlrs_uDqy0pBG3eYQC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
RSTGfX_zpPdAS-yB2dkffiB-rM6278zuDanNFXaOEscC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
AqDFThd6i2ZradBxxPgj8iSl1ZIHzFw6mClJ2fTSX9oC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
g5rarKCGPYw-711M2yaB1Jo4sRa9_YB26IKQoxtRE60C
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
pqNZUNS0AOD30-ODWPT8H1ZM82pmjV5rZbvbhFnHXtsC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
WKRLbWviTHeAaXMNXy4jNbX9mxMwOpX0I5ZHLOClD-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/prpc/mac-amd64
git_revision:edd5644be66d37cdf82978efb0e5d6504d0d552f
C1jj72eXIs6P6BqI5JKCB7aWunWNwM8-0HoioGEbAc8C
[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-386
git_revision:edd5644be66d37cdf82978efb0e5d6504d0d552f
jQzFRINB55LRit23_YVllNePCZscUR9iebEKbvIKB2UC
[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:edd5644be66d37cdf82978efb0e5d6504d0d552f
97GIuWDvHohWyH9KfvpdGiWqPa0MtD__ITW7-lXiNrEC