fix issue with part-handlers and base64 encoding (LP: #874342)

Previously,
 * if content came into cloud-init for processing came in via a multipart
   mime file, and was already base64 encoded, it would get base64 encoded
   again before being handed to a part-handler.
 * if it came in via a '#include'd file then it would not be encoded at
   all.

This drops the internal 'parts' array, that was just converted to and then
from.  Instead, we keep MIME format throughout and keep headers along
the way.

That means that a message that comes in with 'Content-Transfer-Encoding'
set to 'base64' will be decoded before being handed to a part-handler.

It also reduces the chance of failure due to content appearing to be an
actual email.  Previously if content contained colon separated fields, it
might be read as headers (email.message_from_string(open("/etc/passwd","r"))
would come back as all headers, no payload)

The weak point right now is that '#include'd data cannot have mime types
associated with it (unless it is a mime formatted content).  I had hoped
to read user headers and possibly set 'Content-Type' from that.

LP: #874342

1 files changed, 2 insertions, 0 deletions

diff --git a/ChangeLog b/ChangeLog
index 552e1023..3dad0f09 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -15,6 +15,8 @@
  - add 'cloud-init-per' script for easily running things with a given frequency
  - replace cloud-init-run-module with cloud-init-per
  - support configuration of landscape-client via cloud-config (LP: #857366)
+ - part-handlers now get base64 decoded content rather than 2xbase64 encoded
+   in the payload parameter. (LP: #874342)
 0.6.2:
  - fix bug where update was not done unless update was explicitly set.
    It would not be run if 'upgrade' or packages were set to be installed