Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix invalid MIME formatting in multipart cloudinit userdata #13752

Merged
merged 2 commits into from
Apr 21, 2017
Merged

Fix invalid MIME formatting in multipart cloudinit userdata #13752

merged 2 commits into from
Apr 21, 2017

Conversation

devinlundberg
Copy link
Contributor

Per https://tools.ietf.org/html/rfc822#appendix-B.2, MIME headers and Body need to be separated by two new lines (or CRLFs in this case).

The email parser in python can handle this which is what cloud-init uses but this bug causes problems if you try to parse the multipart message by languages other than python.

@devinlundberg
Fix invalid MIME formatting in multipart cloudinit userdata
741364d 
Per https://tools.ietf.org/html/rfc822#appendix-B.2, MIME headers and Body need to be separated by two new lines (or CRLFs in this case). 

The email parser in python can handle this which is what cloud-init uses but this bug causes problems if you try to parse the multipart message by languages other than python.
@radeksimko
Copy link
Member

Hi @devinlundberg
thanks for the contribution, I agree this change makes sense. Just a few points before we can merge this:

  1. One test is now failing, I think it'll need fixing:
=== RUN   TestRender
--- FAIL: TestRender (0.04s)
	testing.go:280: Step 0 error: Check failed: Check 1/1 error: data.template_cloudinit_config.foo: Attribute 'rendered' expected "Content-Type: multipart/mixed; boundary=\"MIMEBOUNDARY\"\nMIME-Version: 1.0\r\n--MIMEBOUNDARY\r\nContent-Transfer-Encoding: 7bit\r\nContent-Type: text/x-shellscript\r\nMime-Version: 1.0\r\n\r\nbaz\r\n--MIMEBOUNDARY--\r\n", got "Content-Type: multipart/mixed; boundary=\"MIMEBOUNDARY\"\nMIME-Version: 1.0\r\n\r\n--MIMEBOUNDARY\r\nContent-Transfer-Encoding: 7bit\r\nContent-Type: text/x-shellscript\r\nMime-Version: 1.0\r\n\r\nbaz\r\n--MIMEBOUNDARY--\r\n"
	testing.go:280: Step 0 error: Check failed: Check 1/1 error: data.template_cloudinit_config.foo: Attribute 'rendered' expected "Content-Type: multipart/mixed; boundary=\"MIMEBOUNDARY\"\nMIME-Version: 1.0\r\n--MIMEBOUNDARY\r\nContent-Disposition: attachment; filename=\"foobar.sh\"\r\nContent-Transfer-Encoding: 7bit\r\nContent-Type: text/x-shellscript\r\nMime-Version: 1.0\r\n\r\nbaz\r\n--MIMEBOUNDARY--\r\n", got "Content-Type: multipart/mixed; boundary=\"MIMEBOUNDARY\"\nMIME-Version: 1.0\r\n\r\n--MIMEBOUNDARY\r\nContent-Disposition: attachment; filename=\"foobar.sh\"\r\nContent-Transfer-Encoding: 7bit\r\nContent-Type: text/x-shellscript\r\nMime-Version: 1.0\r\n\r\nbaz\r\n--MIMEBOUNDARY--\r\n"
	testing.go:280: Step 0 error: Check failed: Check 1/1 error: data.template_cloudinit_config.foo: Attribute 'rendered' expected "Content-Type: multipart/mixed; boundary=\"MIMEBOUNDARY\"\nMIME-Version: 1.0\r\n--MIMEBOUNDARY\r\nContent-Transfer-Encoding: 7bit\r\nContent-Type: text/x-shellscript\r\nMime-Version: 1.0\r\n\r\nbaz\r\n--MIMEBOUNDARY\r\nContent-Transfer-Encoding: 7bit\r\nContent-Type: text/x-shellscript\r\nMime-Version: 1.0\r\n\r\nffbaz\r\n--MIMEBOUNDARY--\r\n", got "Content-Type: multipart/mixed; boundary=\"MIMEBOUNDARY\"\nMIME-Version: 1.0\r\n\r\n--MIMEBOUNDARY\r\nContent-Transfer-Encoding: 7bit\r\nContent-Type: text/x-shellscript\r\nMime-Version: 1.0\r\n\r\nbaz\r\n--MIMEBOUNDARY\r\nContent-Transfer-Encoding: 7bit\r\nContent-Type: text/x-shellscript\r\nMime-Version: 1.0\r\n\r\nffbaz\r\n--MIMEBOUNDARY--\r\n"
  1. I'm marking it as BC. Although the change itself might not be breaking I think many users may be using this in combination with resource like aws_launch_configuration which is by design immutable and any change will therefore cause recreation, so we'll need to mark it as such in the Changelog after merging this.

@radeksimko radeksimko added the waiting-response An issue/pull request is waiting for a response from the community label Apr 20, 2017
@radeksimko radeksimko removed the waiting-response An issue/pull request is waiting for a response from the community label Apr 21, 2017
radeksimko
radeksimko approved these changes Apr 21, 2017
View reviewed changes
Copy link
Member

@radeksimko radeksimko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Thanks, tests are now passing.

@radeksimko radeksimko merged commit 081121d into hashicorp:master Apr 21, 2017
@ghost
Copy link

ghost commented Apr 13, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@radeksimko radeksimko radeksimko approved these changes

Assignees
No one assigned
Labels
breaking-change bug provider/template
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@devinlundberg @radeksimko @grubernaut