[
https://issues.apache.org/jira/browse/CLOUDSTACK-9593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15695511#comment-15695511
]
ASF GitHub Bot commented on CLOUDSTACK-9593:
--------------------------------------------
Github user marcaurele commented on the issue:
https://github.com/apache/cloudstack/pull/1760
right, I forgot about the match required with the version in the pom. I
thought I should prepare the stuff for the next 4.9.x release but that cannot
work unless the pom files are updated too. I will just move the code inside
Upgrade490to4910.java to Upgrade4910to4920.java when it's available.
> User data check is inconsistent with python
> -------------------------------------------
>
> Key: CLOUDSTACK-9593
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9593
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Affects Versions: 4.4.2, 4.4.3, 4.3.2, 4.5.1, 4.4.4, 4.5.2, 4.6.0, 4.6.1,
> 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
> Reporter: Marc-Aurèle Brothier
> Assignee: Marc-Aurèle Brothier
>
> The user data is validated through the Apache commons codec library, but this
> library does not check that the length is a multiple of 4 characters. The RFC
> does not require it either. But the python script in the virtual router that
> loads the user data does check for the possible padding presence, requiring
> the string to be a multiple of 4 characters.
> {code:python}
> >>> import base64
> >>> base64.b64decode('foo')
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File
> "/usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/lib/python2.7/base64.py",
> line 78, in b64decode
> raise TypeError(msg)
> TypeError: Incorrect padding
> >>> base64.b64decode('foo=')
> '~\x8a'
> {code}
> Currently since the java check is less restrictive, the user data gets saved
> into the database but the VR script crashes when it receives this VM user
> data. On a single VM it is not really a problem. The critical issue is when a
> VR is restarted. The invalid pythonic base64 string makes the vmdata.py
> script crashed, resulting in a VR not starting at all.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)