S3 Secret ID's are publicly viewable about s3_website

[laurilehmijoki]

@Aptary Thanks for pointing out the problem. You are right: the s3_website push command should not upload the s3_website.yml file.

When I forked s3_website from jekyll-s3, I forgot to take into account the fact that jekyll copies all the files except the ones starting with an underscore into the site output directory.

Instead of renaming the s3_website.yml file, I propose that we never upload a file named s3_website.yml. The underscore naming convention is particular to jekyll, and I would like to keep s3_website clean of any particular static-website generator's conventions.

While waiting for this bug to be fixed, I recommend that you store your AWS credentials in environmental variables. I'm doing it like this: https://github.com/laurilehmijoki/lauri.lehmijoki.net/blob/master/s3_website.yml.

[laurilehmijoki]

Fixed in version 1.0.2. The commit is here: 6adbb5a.

I recommend all users of this gem to upgrade to that version.

[laurilehmijoki]

Please notice that you still have to delete the s3_website.yml file by hand. s3_website will not delete the file, even though you would upgrade to version 1.0.2. However, as of that version, the command s3_website push will no longer upload the file into S3.

[laurilehmijoki]

The version 1.0.2 reported Uploading 1 new file(s) even though s3_website did not upload anything. This was caused by me placing the blacklist logic, which excludes the s3_website.yml file, into a wrong place. This problem is fixed in the version 1.0.3.

[klausbadelt]

Warning: while this fixes the S3 upload, your s3_website.yml is still in version control, exposing AWS credentials. Using erb/environment tags in s3_website.yml is overwritten by the first s3_website cfg apply. Bug or feature?

[laurilehmijoki]

If the cfg apply command overwrites an existing s3_website.yml file, I'd consider it a bug.