Closed blampe closed 1 year ago
Moving this to a draft to avoid accidental merges. @blampe is looking into reproducing the issue motivating this.
@AaronFriel I haven't been able to repro this. If this PR is low-risk / "can't hurt" then let's deploy it, but I don't feel great not knowing if this will fix the issue or not.
Here's what I've done:
I can confirm this does add the following headers:
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
strict-transport-security: max-age=31536000
name: macos-vm
on:
workflow_dispatch:
jobs:
curl:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os:
- macos-11
- macOS-10.15
endpoint:
- https://get.pulumi-dev.io
- https://get.pulumi.com
steps:
- run: curl -fsSL https://get.pulumi.com | sh
- run: ~/.pulumi/bin/pulumi plugin install resource aws 5.23.0 --server ${{ matrix.endpoint }}
I agree with @kmosher on hardening against MITM.
Looking at is a low risk change, and the CI system tests the installer against pulumi-staging
. I can merge this and validate our install scripts continue to work.
Merging this and deploying to staging, will validate get.pulumi-staging.io
.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-response-headers-policies.html#managed-response-headers-policies-security
Refs https://github.com/pulumi/home/issues/2490
I'm not sure this will resolve the issue. I suggest we try to repo against get.pulumi-staging.io, deploy this change there, and then confirm/deny the fix works. I'm not familiar with how we typically deploy this -- if there's a better way please let me know!