- adding service providers for zone configuration
- getting the python framework working with providers
(cherry picked from commit e0dd12619cc2dc32d23cc1f6cd82f01cd9f80b87)
1. if --prerelease specified, the release number equals to
0.buildnumber
2. if --prerelease omitted, the release number equals to
1 or --release-version if --release-version specified
It’s due to an security fix of OpenJDK 1.6.0 added by Redhat. Here is excerpt
of [RHSA-2011:1380-01] Critical: java-1.6.0-openjdk security update(
https://www.redhat.com/archives/rhsa-announce/2011-October/msg00011.html)
A flaw was found in the way the SSL 3 and TLS 1.0 protocols used block
ciphers in cipher-block chaining (CBC) mode. An attacker able to perform a
chosen plain text attack against a connection mixing trusted and untrusted
data could use this flaw to recover portions of the trusted data sent over
the connection. (CVE-2011-3389)
Note: This update mitigates the CVE-2011-3389 issue by splitting the first
application data record byte to a separate SSL/TLS protocol record. This
mitigation may cause compatibility issues with some SSL/TLS implementations
and can be disabled using the jsse.enableCBCProtection boolean property.
This can be done on the command line by appending the flag
"-Djsse.enableCBCProtection=false" to the java command.
To our knowledge, there are two condition need to be met to trigger this bug:
1. Using old keystore generated by mgmt. server 2.2.8, which is signed with
SHA1withDSA. Any version later than 2.2.8 would generate keystore signed with
SHA1withRSA. RSA one seems fine with us so far.
2. Use OpenJDK >=1.6.0.
The reason is, due to the security fix above, the assumption that one packet
would contain only one SSL record is broken. The decrypted data maybe only
contained the first byte of original application data. Then result in buffer
underflow when mgmt server want to read more from it.
To workaround it, according to the message above, add
"-Djsse.enableCBCProtection=false" to tomcat6.conf JAVA_OPTS line would work.
Notice the parameter would only work with latest version of OpenJDK, so simply
add it to the all setup would not work.
This patch provided a fix for it.
status 11904: resolved fixed
status 11938: resolved fixed
reviewed-by: Frank Zhang
This fix would cover following scenario:
* the customer is upgrading from 2.2.11 to 2.2.13.
* the incorrect indexes are being dropped as a part of 2.2.12 to 2.2.13 upgarde, but we still insert them as a part of 2.2.11 to 2.2.12, and it might lead to the db upgrade failure. The only one way to handle this case - remove them from 2.2.11 to 2.2.12 upgrade path
skip scanning stopped VMs on primary storage if it is not existing, because first time fullsync() called the
primary storage has not been mounted
status 12007: resolved fixed
reviewed-by: edison
Edison Su
Chiradeep Vittal
frank
Prasanna Santhanam
Prasanna Santhanam
Kelven Yang
Abhinandan Prateek
kishan
David Nalley
Alena Prokharchyk
Abhinandan Prateek
Sheng Yang
Alex Huang
root
keshav