Re: Your security@ needs YOU!

[John Kinsella]

HI. WHAT'S WITH THE YELLING? :)

I'm already on security@ and I actively monitor what goes there. About
6 weeks ago a message came through which I missed and nobody else
responded to until ASF security reminded us about the post this
morning.

While having people who "can/will do something" about issues, usually
with appsec you want people who can understand the security aspects,
and then engage developers familiar with the code to help with a fix.
Those who can fulfill both roles are a plus, but not required.

John
ps - your email went into my spam folder...

On Tue, Sep 24, 2019 at 5:04 AM Paul Angus  wrote:
>
> HELLO?
>
>
>
> Have we enough ‘active’ security representatives?
>
>
> Please respond if you are ALREADY on the security maililing list and are 
> still willing/able to assist with CloudStack security issues.
>
> OR
>
> You AREN'T already on the security mailing list, but would like to assist 
> with security issues. Please note 'people with opinions' are welcome, but we 
> very much need 'people who can/will do something about' any issues which are 
> identified.
>
>
> Kind regards
>
>
> Paul Angus

Re: John Kinsella and Wido den Hollander now ASF members

[John Kinsella]

Thanks David and everyone - it really means a lot to me.

Will continue to support and evangelize CloudStack and the ASF where I can!

John 

> On May 2, 2018, at 8:57 AM, David Nalley  wrote:
> 
> Hi folks,
> 
> As noted in the press release[1] John Kinsella and Wido den Hollander
> have been elected to the ASF's membership.
> 
> Members are the 'shareholders' of the foundation, elect the board of
> directors, and help guide the future of the ASF.
> 
> Congrats to both of you, very well deserved.
> 
> --David
> 
> [1] https://s.apache.org/ysxx

New committer: Dag Sonstebo

[John Kinsella]

The Project Management Committee (PMC) for Apache CloudStack has
invited Dag Sonsteboto become a committer and we are pleased to
announce that he has accepted.

I’ll take a moment here to remind folks that being an ASF committer
isn’t purely about code - Dag has been helping out for quite a while
on users@, and seems to have a strong interest around ACS and the
community. We welcome this activity, and encourage others to help
out as they can - it doesn’t necessarily have to be purely code-related.

Being a committer enables easier contribution to the project since
there is no need to go via the patch submission process. This should
enable better productivity.

Please join me in welcoming Dag!

John

Re: [DISCUSS][PROPOSAL] CA authority plugin definition

[John Kinsella]

I’d suggest taking a look at using Dogtag[1] as well. Actually, that’s what the 
Other Guys also suggest[2].

1: http://pki.fedoraproject.org/wiki/PKI_Main_Page 

2: https://wiki.openstack.org/wiki/PKI 


> On Apr 14, 2017, at 7:57 AM, Simon Weller  wrote:
> 
> Daan,
> 
> 
> What about integrating some like Vault (https://github.com/hashicorp/vault 
> )?
> 
> 
> - Si
> 
> 
> From: Daan Hoogland  >
> Sent: Friday, April 14, 2017 5:46 AM
> To: dev@cloudstack.apache.org 
> Subject: [DISCUSS][PROPOSAL] CA authority plugin definition
> 
> Devs,
> 
> Following a discussion with a client they came up with the idea to create a 
> pluggable CA-framework. A plugin would serve components in cloudstack that so 
> require (management servers, agents, load balancers, SVMs, etc.) with 
> certificates answering certificate requests and validating certificates on 
> request.
> 
> A default plugin can be written that serves according to its own self signed 
> root certificate and have its own revocation list to be managed by the admin. 
> Other plugin could forward by mail or web requests to external parties.
> 
> A CA-plugin will have to
> 
> -  Setup, for the default this means creating its certificate, for 
> others it might mean install an intermediate certificate or configure a mail, 
> or website address.
> 
> -  Accept and answer certificate requests
> 
> oFor client certificates
> 
> oFor server certificates
> 
> -  Accept revocation requests
> 
> -  Validate a connection request according to origin and certificate 
> and . What extra data is is defined by the plugin and can be 
> credentials or field-definitions referring the x509 entries or for instance 
> port numbers allowed… this is basically free to the implementer.
> 
> A next step will have to be integrating the request calls with installs on 
> targets but I think as is this feature merits itself as it could be used with 
> out of band configuration management tools as well.
> 
> Any thoughts, remarks and critiques are welcome,
> 
> daan.hoogl...@shapeblue.com
> www.shapeblue.com  >
> Shapeblue - The CloudStack Company >
> www.shapeblue.com 
> Background Cloudstack relies on a fixed download site when it fetches the 
> built-in guest VM templates. That download site has historically
> 
> 
> 
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue

Re: re-introduction

[John Kinsella]

Welcome back! :)

> On Feb 1, 2017, at 12:26 AM, Daan Hoogland  
> wrote:
> 
> Hello,
> 
> 
> My name is Daan Hoogland. I've been mostly out of the community since May 
> last year. I am now back through the generous sponsorship of my new employer 
> and will be working (mostly) as developer on cloudstack.
> 
> For those who remember me and are curious, I've been learning some scala and 
> some rust in the meanwhile and have been working on financial middleware in 
> between.
> 
> 
> I expect to have good times back in here :)
> 
> daan.hoogl...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, Utrecht Utrecht 3531 VENetherlands
> @shapeblue
> 
> 
> 

Re: [DISCUSS] Bountycastle upgrade

[John Kinsella]

2 thoughts:

1) I know this is partially git’s fault on the diff, and i know this is a 
standard gripe from me, but for reviewers things are much easier if 
syntax/whitespace changes are separated out into a separate patch from 
logic/functionality.
2) One thing that caught my eye was the SHA-1 use on the fingerprint. That got 
me looking around the codebase, and I see SHA-1/SHA1 sprinkled around. It’s not 
considered secure anymore [1]. Some of the uses are just for naming, that’s 
fine. I don’t think any of the use I saw was OMGFIXNOW. But at some point might 
be nice to replace all that with SHA-256. Would require a data migration, 
though.
3) Awesome, run with it. :)

John
1: https://en.wikipedia.org/wiki/SHA-1#Cryptanalysis_and_validation

> On Dec 1, 2016, at 10:17 PM, Rohit Yadav  wrote:
> 
> All,
> 
> 
> I've sent a PR that will upgrade bountycastle dependency to the latest 
> version [1]. In terms of security, an upgrade is necessary though it would 
> also require for users (who are upgrading to 4.9.1.0, 4.10.0.0 or later) to 
> destroy old systemvms such as CPVM and SSVM so the agents that will be 
> started in new system vms will use the same dependency jar (version/release) 
> and use the same cipher suites as the mgmt server (i.e. there will be no 
> SSL-based communication issue afterwards) as provided by bountycastle v1.55.
> 
> 
> Thoughts, feedback?
> 
> 
> [1] https://github.com/apache/cloudstack/pull/1799
> 
> 
> Regards.
> 
> rohit.ya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 

CVE-2016-6813: Apache CloudStack registerUserKeys authorization vulnerability

[John Kinsella]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

CVE-2016-6813: Apache CloudStack registerUserKeys authorization vulnerability

CVSS v3:
9.1 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:L)

Vendors:
The Apache Software Foundation
Accelerite, Inc

Versions affected:
CloudStack versions 4.1 and newer are affected by this issue.

Description:
Apache CloudStack contains an API call[1] designed to allow a user
to register for the developer API.  If a malicious user is able to
determine the ID of another (non-"root") CloudStack user, the
malicious user may be able to reset the API keys for the other user,
in turn accessing their account and resources.

Mitigation:
Some users may be protected from this weakness already, if they
have configured their commands.properties file to limit access to
this api call from the integration API port, instead of general API
port. This can be accomplished by setting registerUserKeys to 1.

Users of Apache CloudStack version 4.9 whom are using the dynamic
roles feature can delete the "Allow" rule for "registerUserKeys"
for each non-administrator role under the Roles/Rules section of
the user interface.

Alternately, users of Apache CloudStack should upgrade to one of
the following versions, based on which release they are currently
using: 4.8.1.1, or 4.9.0.1. These versions contain only security
updates, and no other functionality change. Full details about the
security releases can be found at [2]

Credit:
This vulnerability was reported by Marc-Aurèle Brothier from Exoscale.

1: https://cloudstack.apache.org/api/apidocs-4.8/user/registerUserKeys.html
2: https://s.apache.org/qV5l
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCgAGBQJYEg0wAAoJEOom9N0pCN7SK2kP/jnhxB4u1wUaf32N2EWVbPur
uv1CarrwkV7XDlmlmcBn2G7uitPO6hbDMf9z+ZB55d5pnc5EwMluUltWjwsa2ixm
aMkqepr1wNIKZkJkPo8dlpoEHtqzv3WiY4i18TS7kUV8cjUuWe0UHB3Tj4QSSTAF
CbuQhl3+xJ5S0aU2LV5buHrhbbPCpTBzK5p2NFP2Bq1YEjdh1vsXpeoJM1miKyb+
/gTt79SNDbTRmoy5zp2dtJ10nZFxW04gEAjGyV8JJlhDJhgQo3F9zVKbyIbGcDJ6
ZFJkl90EptO/ebePJ9LmV3uLYUMm21DzfcF/b2TwzaOmvIpVou0dSqqGBBsgiGbl
OFm/7YRTbBDS6w5tFtUXta4LWWEBr3tyirB2X+Qi5Ctqw5HJSmhL2yyiPYtKKKpx
pp3tOQw5oho/Qkm0Xt0ClpHfF+K5ndGWw7gbpwPdF+XpsCPciuM7LhhI1db67Azu
eY9O69fY4daX4QsppT+cBX1Yc47ZTwHJvVCSvUQLr7KHBuxCF62S52i92bknE06F
WsRlNZT8HzBMI82PImVLCreO0Eh7QgouWsDoadqeCGQw97FBXF3aLkSji90hLy6y
DO6ucUKqRwtGP9orhCB7fsK4SKFYCy4xwIUMPxY3SHahiruZEV/II8GrptyOWWLV
0K9uAQryK2GZ3Nmml1r4
=o0kf
-END PGP SIGNATURE-

CVE-2016-3085: Apache CloudStack Authentication Bypass Vulnerability

[John Kinsella]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

CVE-2016-3085: Apache CloudStack Authentication Bypass Vulnerability

CVSS v2:
7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)

Vendors:
The Apache Software Foundation
Accelerite, Inc

Versions affected:
CloudStack versions 4.5.0 and newer

Description:
Apache CloudStack contains an authentication module providing “single
sign-on” functionality via the SAML data format. Under certain
conditions, a user could manage to access the user interface without
providing proper credentials. As the SAML plugin is disabled by
default, this issue only affects installations that have enabled
and use SAML-based authentication.

Mitigation:
Users of Apache CloudStack using the SAML plugin should upgrade to
one of the following versions, based on which release they are
currently using: 4.5.2.1, 4.6.2.1, 4.7.1.1, or 4.8.0.1. These
versions contain only security updates, and no other functionality
change.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCgAGBQJXWNuFAAoJEOom9N0pCN7Sw8EP/0Q5YgomRGEocod2Cmlfd/E9
JKSBdt38hTclPXcdi3w/1Fq88l54erfHuPLPJObpsIR/vQGiOU0K9KkaO5jYDHtR
uFzb37PDzkR/x0tpfOvl1LqWOl89dSjF0qNAB8gi5ThqSWhBst70bjq0bR1aFxXx
I05JzZgD4eye+3tYRcVoFPOkbP7E5pWFtPo9LKUdRL4bfSwskB7d5MOGUoBMQfBb
vuMp7BikT3kMU7kiXNHKMCdd24iAQeiMOocZo7fPn70DiKANqLzinLxlWZHrd4Lh
IPO/m35s52tIVFxXAIF5N7ThAhOCoqQykxykCAgZN1Wi5444/bBJ/ppaP3StWq8i
gRTPzVYbniCTUfG4ynGZIwLwdDJxMb4M1kBdT3lpQWRhq24vE7/xSPANy8ipegvw
rZ8EYS0b0Ud4Bx60+L3rCMBJAwlSaddX/DDHaYUU8hxT5NRoK0eiWf9p4jd40Ob4
BYM/9mi4tv4Wq6tIEqSZfVMdNKgY3+0oBP5HEhEmXSk9Th0rNLySB7Xpix7dC5iF
4I0kpki8BFirE6rBGiKNARdXZJ9QTUTUG/wk1Ndgoe4kJG3PtR6PuY9DAWomqecz
aF/tmyIZXLeVEyZrS1rKLPlIjRHarALoQgB0Ln+UAhS0oyVJ5LrR4Ie70UDCMRNv
rNjki8AjTUnQarsp14lT
=+Tpv
-END PGP SIGNATURE-

Fwd: [DISCUSS] Move from OpenSSL to LibreSSL

[John Kinsella]

(whoops - accidentally replied privately, bringing back to mailing list - hope 
Vadim’s OK with that)

Realize the SSVM and VR provide “public” services - https is open on the 
console proxy, vpn services are open on the virtual router. 

And unfortunately yes, people usually only think about improving security after 
issues are found - that’s why security geeks like me are around. :)

I’ll see if I can drop in libressl in the next week or two and see what 
happens….

John

> Begin forwarded message:
> 
> From: Vadim 
> Subject: Re: [DISCUSS] Move from OpenSSL to LibreSSL
> Date: February 4, 2016 at 11:43:07 PM PST
> To: John Kinsella 
> 
> Thank you for explanation, John.
> 
> I am not involved into CS security assessment, but existing architecture 
> makes me feel safe, because SSVM and VR and any other system VM is accessible 
> (by SSH) only from hypervisor host due to link-local address limitation. I 
> don't know other ways, but it doesn't mean they do not exist.
> 
> I do share your worries about OpenSSL library vulnerabilities, especially 
> after "heartbleed", but replacing it everywhere seems to be very hard task.  
> I don't think you will have discussion in this list on the subject unless 
> next "heartbleed" happens.  
> Vadim.
> 
>  
> On 2016-02-04 18:01, John Kinsella wrote:
> 
>> Hey Vadim - I should have clarified, sorry...
>> 
>> SSL libraries are used in several areas in an ACS installation:
>> 
>> 1) On management server, for secure communication with management UI, APIs, 
>> etc.
>> 2) On system VMs - console proxies, secondary storage VMs, and possibly 
>> virtual routers (this is off top of my head, need to confirm).
>> 
>> On management servers, whoever's building the system can choose whatever 
>> they want - you are correct here. What I was originally referring to was the 
>> second bullet - these are usually pre-built VM images downloaded into a 
>> CloudStack environment. That build is generated by ACS code, which currently 
>> uses OpenSSL. That's where I'm asking should we consider using LibreSSL 
>> instead.
>> 
>> John
>> 
>>> On Feb 4, 2016, at 7:47 AM, Vadim mailto:va...@ant.ee>> 
>>> wrote:
>>> 
>>> John,
>>> 
>>>Can CS community decide that? From my point of view this is OS 
>>> distribution owner who does. OpenSSL is system package and you probably 
>>> can't skip it, unless you create your own Linux distribution.
>>> 
>>> Vadim.
>>> 
>>> On 2016-02-03 17:48, John Kinsella wrote:
>>> 
>>>> Folks - another OpenSSL vulnerability was announced last week[1]. I 
>>>> believe our current SSVMs are running Wheezy, so they should be OK 
>>>> according to [2].
>>>> This makes me ponder, though: Should we consider moving to LibreSSL[3] in 
>>>> the future? For those not familiar, it's a fork of OpenSSL with more 
>>>> emphasis on cleaning up the code and improving the security of the 
>>>> codebase.
>>>> From what I've seen so far, it should be a "drop in" replacement for 
>>>> OpenSSL, but I haven't tested that theory out yet.
>>>> I originally brought this up on security@, but it was quickly pointed out 
>>>> as it's not an actual vulnerability in ACS we should discuss in public, so 
>>>> here we are.
>>>> Looking for thoughts, maybe somebody has experience moving from OpenSSL to 
>>>> LibreSSL in another project?
>>>> John
>>>> 1: https://www.openssl.org/news/secadv/20160128.txt 
>>>> <https://www.openssl.org/news/secadv/20160128.txt>
>>>> 2: https://security-tracker.debian.org/tracker/CVE-2016-0701 
>>>> <https://security-tracker.debian.org/tracker/CVE-2016-0701>
>>>> 3: http://www.libressl.org/ <http://www.libressl.org/> 
>  

Two late-announced security advisories

[John Kinsella]

Folks - I just sent out 2 security advisories that should have been sent out 
several months ago - luckily the ASF security team was aware of them and 
prodded the ACS security team as to what was up. Earlier today I realized the 
announcements hadn’t gone out, so they were just sent.

I just put up a blog post[1] explaining how this happened and what we’re going 
to do in the future to minimize the chance of it happening again.

If folks have further questions about the advisories or the mixup in posting 
them, I’m happy to discuss privately or on-list.

With apologies...

John
1: 
https://blogs.apache.org/cloudstack/entry/two_late_announced_security_advisories

CVE-2015-3251: Apache CloudStack VM Credential Exposure

[John Kinsella]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

CVE-2015-3251: Apache CloudStack VM Credential Exposure

CVSS v2:
6.0 (AV:N/AC:M/Au:S/C:P/I:P/A:P)

Vendors:
The Apache Software Foundation
Citrix, Inc.

Versions Afffected:
Apache CloudStack 4.4.4, 4.5.1

Description:
Apache CloudStack provides an API for managing network, compute,
storage, and user aspects of a CloudStack cloud. Under certain
circumstances, the results of certain API calls may expose the root
password for a virtual machine related to an API call.

This exposure only happens when the API calls of concern are
authenticated with CloudStack's "root" or "domain administrator"
level users.

Mitigation:
Users of Apache CloudStack should update to at least 4.5.2 or 4.6.0.
Additionally ensure non-administrative users do not have root or
domain-administrator level accounts.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCgAGBQJWs/YVAAoJELAo8zo1KBbt+wwP/37SL6e157Hil+unxdV2eqIv
swtRKbEAn6EHRU8xbN+nX/CqbRoonNY8xRAh2R3t6qMjvQwma+fNjKYrQRY476Vr
m4pib/zBf10/lvb2oLppMPMDuAA0ri24UCD/iGS+9aRq72nphDudgxAHHySo9xki
MyJM7Pih+2DkBAbBkQfgxq3juIIc6kgTfdQnKDTrCAMqrD5hSAEjWkfdoKdaRBwn
iMnueNcu0TAyUFpFKz/mbKX4K1ZN7CKykhWGzZI3CO5Cze9u7HfbuqI4Dh2YOWIR
94dQHcGUEAg6d4laL/R0k2PsWSKAjhlwrATC7Th1+N4JR67SxskM9zNDpi7qU7zp
DKqXHbgJ32KH1V0jD/aoGFEgsusUzuJ9yNRX3Mr4TVyfPmTzN1w/NtKl/tqJidba
Mxv8KJFTtOY5OnuD01tnoLIUPXxQcw6uS0Zoqg8ns0TqkdTCW5BmnhLfNfIb9dlp
/zYNl/wFKGv68x6YZmWme6bXNg7l1KKYnK0Yb6Po7JX6k94/vAsMTsPkgdGjTq7L
HqdnwvAAiqEloWZe8trrzMqSRdr6TKhSTWqN3yWaMqQEml/VakCDYGrdd+rDdp/P
++zqLsDUXTaTsipYM/e/oipRtRcHa/TXxERMcH0S4R2rId2mk6X2fyHGoar7p/oG
/Ef3ZKcqB6rxdzKYLEV7
=t8DZ
-END PGP SIGNATURE-

CVE-2015-3252: Apache CloudStack VNC authentication issue

[John Kinsella]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

CVE-2015-3252: Apache CloudStack VNC authentication issue

CVSS v2:
4.3 (AV:N/AC:H/Au:M/C:P/I:P/A:P)

Vendors:
The Apache Software Foundation
Citrix, Inc.

Versions Afffected:
Apache CloudStack 4.4.4, 4.5.1

Description:
Apache CloudStack sets a VNC password unique to each KVM virtual
machine under management. Upon migrating a VM from one host to
another, the VNC password is no longer set in KVM on the new host.

To leverage this issue, an attacker would need to have network
access to a CloudStack host to be able to connect via VNC directly.

Mitigation:
Users of Apache CloudStack and derivatives should ensure their hosts
are behind network firewalls, and should update to least version
4.5.2 or 4.6.0, depending on which tree is being used.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCgAGBQJWs/dCAAoJELAo8zo1KBbtsX8QAMf2s9OIY3FTbMbTIo/LBmLa
rOOE46SBcmypN1TCHKW0K9etymieI58CPX9LHNdtZcAMa1khl4uo/Euz0wGu0zZZ
awXahXEKUkLSTQDDYJP+8TmKvnIan/mYXRvPEHi2bMCtQ+CjY5qvcge9wXpFDKty
B3LP9n/zYDkQCvBLmjPuqIM+B4JXT9q/e3LsVQHrjhBxheY26CMrSRZ/aLxmzxbh
SSNs4oMZhLEPHoSt/lWsHYd/HxJ/eEjyQunP0UpO5d5/RZypYllPHcbaFPqtC4uK
55VB3JGyPiSEpxbbWEAqrPlOwCU9yNhRXnjdf3gc360NtdjncY1R49+VvUc6C+6u
FqPmy5LFja5uQ1w6/VDdwoT9GeBL9rooMFsLgRpv+FCKPYEtvvIbvot45xA5TCAi
MoU7RjYZoWHTmXLYcQOSSzFnySjLVqdrIL6fgu4gpehB/Od+sV+dwaKM/l03Ml8S
mTerjUNkG2e+pNuWk703aLv4YrKv63T2ga8Nli00BYSyzsxDupd+0XmBzvsLPCMY
uEbxBVVFSpIJMtTacBNgRQGFEQVh+DxPgDaXoZ6RFU/QKVZuWAq85qVEcbDjf8bM
0C6D3f5uXaFaXm4ff1FZ/s/4YOj4rm5EyawrM+Me218+PKMJPHzvsL8y10GCj1T8
s1S77QqgKhqFc+98Z1m3
=OY+T
-END PGP SIGNATURE-

Re: [RESULT][VOTE] Apache CloudStack 4.7.0

[John Kinsella]

Did the announcements for 4.7/4.8 go out? I don’t see them on the mailing lists 
or elsewhere?

> On Dec 17, 2015, at 8:37 AM, Remi Bergsma  wrote:
> 
> Hi all,
> 
> After 72 hours, the vote for CloudStack 4.7.0 [1] *passes* with 5 PMC + 1 
> non-PMC votes.
> 
> +1 (PMC / binding)
> * Wilder
> * Wido
> * Milamber
> * Rohit
> * Remi
> 
> +1 (non binding)
> * Boris
> 
> 0
> * Abhinandan
> * Dag
> * Glenn
> 
> -1
> Raja (has been discussed, seems local test configure issue)
> 
> Thanks to everyone participating.
> 
> I will now prepare the release announcement to go out after 24 hours to give 
> the mirrors time to catch up.
> 
> [1] http://cloudstack.markmail.org/message/aahz3ajryvd7wzec
> 

[DISCUSS] Move from OpenSSL to LibreSSL

[John Kinsella]

Folks - another OpenSSL vulnerability was announced last week[1]. I believe our 
current SSVMs are running Wheezy, so they should be OK according to [2].

This makes me ponder, though: Should we consider moving to LibreSSL[3] in the 
future? For those not familiar, it’s a fork of OpenSSL with more emphasis on 
cleaning up the code and improving the security of the codebase.

From what I’ve seen so far, it should be a “drop in” replacement for OpenSSL, 
but I haven’t tested that theory out yet.

I originally brought this up on security@, but it was quickly pointed out as 
it’s not an actual vulnerability in ACS we should discuss in public, so here we 
are.

Looking for thoughts, maybe somebody has experience moving from OpenSSL to 
LibreSSL in another project? 

John
1: https://www.openssl.org/news/secadv/20160128.txt
2: https://security-tracker.debian.org/tracker/CVE-2016-0701
3: http://www.libressl.org/

Re: cloudstack vulnerable by COLLECTIONS-580?

[John Kinsella]

Thanks for sending this, Rene. In the future, please send issues like this to 
secur...@cloudstack.apache.org.

We’re looking things over, and will have further comments after review.

John

On Nov 10, 2015, at 6:07 AM, Rene Moser 
mailto:m...@renemoser.net>> wrote:

Hi

This security issue came to my attention:
https://issues.apache.org/jira/browse/COLLECTIONS-580

See
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
for more background information.

I am not sure if cloudstack is affected, at least we have dependency to
this vulnerable lib:

$ grep -Rl InvokerTransformer .
./plugins/hypervisors/kvm/target/dependencies/commons-collections-3.2.1.jar
./client/target/cloud-client-ui-4.5.2.war
./client/target/cloud-client-ui-4.5.2/WEB-INF/lib/commons-collections-3.2.1.jar
./usage/target/dependencies/commons-collections-3.2.1.jar
./agent/target/dependencies/commons-collections-3.2.jar
./engine/service/target/engine/WEB-INF/lib/commons-collections-3.2.jar

Thanks for clarification.

Yours
René

Xen security issue

[John Kinsella]

Folks running paravirtualized VMs on Xen (3.4 and newer) hosts need to patch to 
protect against a new vulnerability that allows an admin in a VM to escape up 
to the host:

http://xenbits.xen.org/xsa/advisory-148.html

John

Stratosec - Secure Finance and Heathcare Clouds
http://stratosec.co
o: 415.315.9385
@johnlkinsella

Re: [Proposal] Replacing Openswan ipsec with Strongswan ipsec

[John Kinsella]

+1. The config formats are sometimes a little different, but overall 
functionality is similar. This should be fairly transparent to the end user, as 
the configurations are (usually) generated by ACS.

John

> On Jul 24, 2015, at 3:10 PM, Jayapal Reddy Uradi 
>  wrote:
> 
> Hi All,
> 
> Openswan is not being actively maintained by community.
> Any security updates to the packages then it is difficult to upgrade.
> latest version of OS X clients are not working on openswan.
> 
> To address the above concerns I am proposing to move from openswan ipsec to 
> strongswan ipsec.
> 
> I will be sharing the FS for this feature soon.
> 
> Thanks,
> Jayapal
> 
> 

Re: openssl/cloudstack

[John Kinsella]

Update - looks like there’s no exposure to the vulnerability for us. The Debian 
images we use do not use a vulnerable version of OpenSSL.

Thanks for the patience!

John

On Jul 10, 2015, at 10:19 AM, John Kinsella 
mailto:j...@stratosec.co>> wrote:

Folks - just put up a brief blog post about the latest OpenSSL issue and how 
that affects CloudStack. Long story short - we think it does, but are verifying 
that. Hopefully will have an update by the end of the day.

https://blogs.apache.org/cloudstack/entry/cloudstack_and_openssl_cve_2015

Will update here and on the blog/twitters as we know more.

John

openssl/cloudstack

[John Kinsella]

Folks - just put up a brief blog post about the latest OpenSSL issue and how 
that affects CloudStack. Long story short - we think it does, but are verifying 
that. Hopefully will have an update by the end of the day.

https://blogs.apache.org/cloudstack/entry/cloudstack_and_openssl_cve_2015

Will update here and on the blog/twitters as we know more.

John

Re: Access to ACS security issues

[John Kinsella]

Wilder - sorry, I don’t see in my inbox/spam folder. :( Could ya forward to me 
directly?

URLs or bug numbers would be handy, just so we know we’re looking at same 
thing...

John

> On Jun 10, 2015, at 1:09 PM, Wilder Rodrigues  
> wrote:
> 
> Hi John,
> 
> I sent the not to the security list, haven’t got an reply yet.
> 
> Do you need to know which issues did Glenn create? Please, let me know and we 
> will provide you the URLs.
> 
> Thanks in advance.
> 
> Cheers,
> Wilder
> 
>> On 10 Jun 2015, at 19:00, John Kinsella  wrote:
>> 
>> +1. We can run queries for security issues, but that requires a more 
>> proactive stance than (at least some of us) honestly have. Send a note to 
>> the list mentioned…we don’t bite. :)
>> 
>> John
>> 
>>> On Jun 10, 2015, at 5:20 AM, David Nalley  wrote:
>>> 
>>> Any chance we can get Glenn to follow our security vulnerability
>>> reporting procedure?
>>> https://cloudstack.apache.org/security.html
>>> 
>>> The issue with creating 'private Jiras' is that no one gets notified.
>>> Indeed, this email is the first notice that any of us have about these
>>> issues.
>>> 
>>> --David
>>> 
>>> On Wed, Jun 10, 2015 at 4:22 AM, Wilder Rodrigues
>>>  wrote:
>>>> Hi all,
>>>> 
>>>> Our colleague Glenn reate some security issues under the ACS Jira with 
>>>> private visibility. I would like to have a look at those issues, but 
>>>> unfortunately I do not have access even to browse those.
>>>> 
>>>> How could we get that solved? Is that possible to give me access?
>>>> 
>>>> Thanks in advance.
>>>> 
>>>> Cheers,
>>>> Wilder
>> 
> 

Re: Access to ACS security issues

[John Kinsella]

+1. We can run queries for security issues, but that requires a more proactive 
stance than (at least some of us) honestly have. Send a note to the list 
mentioned…we don’t bite. :)

John

> On Jun 10, 2015, at 5:20 AM, David Nalley  wrote:
> 
> Any chance we can get Glenn to follow our security vulnerability
> reporting procedure?
> https://cloudstack.apache.org/security.html
> 
> The issue with creating 'private Jiras' is that no one gets notified.
> Indeed, this email is the first notice that any of us have about these
> issues.
> 
> --David
> 
> On Wed, Jun 10, 2015 at 4:22 AM, Wilder Rodrigues
>  wrote:
>> Hi all,
>> 
>> Our colleague Glenn reate some security issues under the ACS Jira with 
>> private visibility. I would like to have a look at those issues, but 
>> unfortunately I do not have access even to browse those.
>> 
>> How could we get that solved? Is that possible to give me access?
>> 
>> Thanks in advance.
>> 
>> Cheers,
>> Wilder

Re: refresh browser - logged out from ACS ?

[John Kinsella]

Thanks for bringing the topic up. As it’s not related to a specific 
vulnerability or something that needs to be discussed in private, I’ll keep the 
conversation on dev@. Generally I’m happy to see discussions about security 
design happen in public so all can learn. This convo hit my filters so I was 
aware of it before the cc to security@, but when in doubt send it over there 
(obviously gets more eyes than my email filters do).

For those new, you’ll find we’re generally not the corporate “security mafia” 
types who blindly follow Process & Procedure. :)

My first comment - I’m not a fan of breaking functionality in the name of 
“security” unless it’s really, really necessary. I too thought this one had 
been straightened out already, but I guess not.

What Rafael’s doing looks reasonable…I haven’t looked through the UI code too 
much, but my sense is this is a “code smell” that there’s more places this 
needs to be fixed besides just here (I could be wrong). 

Restoring functionality - good.
Keeping things secure - good.
Improving the security design - great. :)

Carry on!

John
ps - Regarding the non-viewable tickets, our process is to mark them as public 
once the issue has been fixed/released. Sounds like we might be due for a 
little housecleaning to see what issues have the security flag set and are 
marked closed...

> On May 27, 2015, at 3:56 AM, Stephen Turner  wrote:
> 
> I've got no specific view on your change, Rafael: I just think security 
> matters should be discussed on the security list. I'm copying this email to 
> them.
> 
> -- 
> Stephen Turner
> 
> 
> -Original Message-
> From: Rafael Fonseca [mailto:rsafons...@gmail.com] 
> Sent: 27 May 2015 11:50
> To: dev@cloudstack.apache.org
> Subject: Re: refresh browser - logged out from ACS ?
> 
> Well, if just 'discuss' an issue with a security team, it may do you no good 
> as they will not have all the answers without actually testing/reviewing If 
> you ask a security team if you should have a client handled cookie with 
> credentials they will immediately tell you it's not wise to do so, but they 
> will probably not guess that the same data is just getting kept in a js 
> variable or they would also advise against it.
> I think that it's clear that my approach improves security and restores 
> functionality (just read a bit about handling sensitive data on js side and 
> have a quick look at my code in the PR) Although this does not propose to be 
> a magical security solution, it DOES improve on current security and DOES 
> restore a broken functionality.
> 
> Feel free to move this to the security list, but ultimately all users should 
> be able to view the status in the PR.
> 
> 
> On Wed, May 27, 2015 at 12:27 PM, Stephen Turner 
> wrote:
> 
>> I know for sure it was discussed with Citrix security team before 
>> changing it. Probably also on the ACS security list, but I'm not on that 
>> list.
>> Anyway, even if the security concern turns out to be illusory, we 
>> shouldn't change a claimed security fix without taking it back to the 
>> security list.
>> 
>> --
>> Stephen Turner
>> 
>> 
>> -Original Message-
>> From: Rafael Fonseca [mailto:rsafons...@gmail.com]
>> Sent: 27 May 2015 11:16
>> To: dev@cloudstack.apache.org
>> Subject: Re: refresh browser - logged out from ACS ?
>> 
>> This doesn't really do much for security, since the sessionKey is 
>> still available to JS in a window variable, so this mostly just breaks 
>> functionality and adds no value.
>> This probably wasn't discusses with security experts before 
>> implementation, so this just breaks functionality period.
>> My approach does indeed add some security (set a httponly cookie with 
>> the
>> data) and restores session persistence.
>> 
>> 
>> 
>> On Wed, May 27, 2015 at 11:50 AM, Stephen Turner < 
>> stephen.tur...@citrix.com>
>> wrote:
>> 
>>> Is this being discussed on the security list? I think that's the 
>>> place for it, because I wouldn't want us to restore the old 
>>> behaviour without a proper audit from security experts.
>>> 
>>> --
>>> Stephen Turner
>>> 
>>> 
>>> -Original Message-
>>> From: Rafael Fonseca [mailto:rsafons...@gmail.com]
>>> Sent: 27 May 2015 10:39
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: refresh browser - logged out from ACS ?
>>> 
>>> Hi guys,
>>> 
>>> I had a look at this issue yesterday and created a PR to fix it, 
>>> it's being discussed here 
>>> https://github.com/apache/cloudstack/pull/308
>>> Since this seems to be a security related issue I will be updating 
>>> my PR soon with a secure fix :)
>>> 
>>> On Wed, May 27, 2015 at 11:24 AM, Andrija Panic 
>>> 
>>> wrote:
>>> 
 its not the case with i.e. 4.3.2...its is the case with 4.4.3 and
 4.5.1 at the moment...
 
 On 27 May 2015 at 11:20, Vadim Kimlaychuk 
 
 wrote:
 
> Is it possible to fix? It seems such a behaviour was always be 
> like
>>> this.
> 
> Vadim.
> 
> -Original Message-

Re: ACS 4.5 Release [URGENT]

[John Kinsella]

I can’t think of a reason to provide packages? People will go looking for them, 
so maybe document somewhere the reason for skipping…


On Mar 10, 2015, at 9:27 AM, Wido den Hollander 
mailto:w...@widodh.nl>> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 03/10/2015 04:56 PM, David Nalley wrote:
So 4.5.0 has shipped - it's been propogated to hundreds of
mirrors, and undoing that is not trivial. IMO, we should patch, and
kick out another RC for 4.5.1 (or 4.5.0.1 I suppose)

Version numbers are cheap to increment.


But shall we stay away from building packages then? 4.5.0 will simply
not be released in DEB or RPM format.

I'm aware that a Apache project only releases source, but our end
users use packages.

Wido

--David

On Tue, Mar 10, 2015 at 7:37 AM, Nux! mailto:n...@li.nux.ro>> 
wrote:
Agreed.

One more RC, please, David?

-- Sent from the Delta quadrant using Borg technology!

Nux! www.nux.ro

- Original Message -
From: "Abhinandan Prateek" 
mailto:abhinandan.prat...@shapeblue.com>>
To: dev@cloudstack.apache.org Sent: Tuesday, 
10 March, 2015
11:31:40 Subject: Re: ACS 4.5 Release [URGENT]


On 03/10/2015 11:45 AM, Geoff Higginbottom wrote:
@PMC

Whilst the Vote has officially passed, we have not
announced it yet so still have time to retract the release,
fix and then potentially re-vote etc.


This seems like a serious issue to me. Rules not applying on
a VR is a big problem.

We should release good software instead of broken versions,
since that will damage the reputation of CloudStack.

I do agree here. We should fix it and then ship.


Wido

Regards

Geoff Higginbottom

D: +44 20 3603 0542 | S: +44 20 3603
0540 | M:
+447968161581

geoff.higginbot...@shapeblue.com



From: Paul Angus [mailto:paul.an...@shapeblue.com] Sent: 10 March
2015 10:28 To: dev@cloudstack.apache.org 
Subject: ACS 4.5
Release [URGENT] Importance: High

Hi All,

Given that the release 4.5 vote passed, with the blocker
https://issues.apache.org/jira/browse/CLOUDSTACK-8248 which
had the knock on effect of
CLOUDSTACK-8305





VPC ACL Rules are not applied to Virtual
Router



Do we have a mechanism to recall/annul that RC vote and use a build
with the fixes in?  I have a horrible feeling that it would
require another round of voting, but that has to be better
than shipping a broken product.



Regards

Paul Angus Cloud Architect

[cid:image001.png@01D01549.640501B0]

D: +44 20 3468 5163 |S: +44 20 3603
0540 | M: +44 7711
418 784 | T: @CloudyAngus
paul.an...@shapeblue.com
| www.shapeblue.com |
Twitter:@shapeblue ShapeBlue Ltd, 53
Chandos Place, Covent Garden, London, WC2N 4HS

Find out more about ShapeBlue and our range of CloudStack
related services

IaaS Cloud Design &
Build
CSForge - rapid IaaS deployment
framework CloudStack
Consulting
CloudStack Software
Engineering


CloudStack Infrastructure
Support


CloudStack Bootcamp Training
Courses

This email and any attachments to it may be confidential
and are intended solely for the use of the individual to
whom it is addressed. Any views or opinions expressed are
solely those of the author and do not necessarily represent
those of Shape Blue Ltd or related companies. If you are
not the intended recipient of this email, you must neither
take any action based upon its contents, nor copy or show
it to anyone. Please contact the sender if you believe you
have received this email in error. Shape Blue Ltd is a
company incorporated in England & Wales. ShapeBlue Services
India LLP is a company incorporated in India and is
operated under license from Shape Blue Ltd. Shape Blue
Brasil Consultoria Ltda is a company incorporated in Brasil
and is operated under license from Shape Blue Ltd.
ShapeBlue SA Pty Ltd is a company registered by The
Republic of South Africa and is traded under license from
Shape Blue Ltd. ShapeBlue is a registered trademark. Find
out more about ShapeBlue and our range of CloudStack
related services

IaaS Cloud Design &
Build
CSForge - rapid IaaS deployment
framework CloudStack
Consulting
CloudStack Software
Engineering


CloudStack Infrastructure
Support

Re: ACS 4.5 Release [URGENT]

[John Kinsella]

+1

> On Mar 10, 2015, at 8:56 AM, David Nalley  wrote:
> 
> So 4.5.0 has shipped - it's been propogated to hundreds of mirrors,
> and undoing that is not trivial.
> IMO, we should patch, and kick out another RC for 4.5.1 (or 4.5.0.1 I suppose)
> 
> Version numbers are cheap to increment.
> 
> --David
> 
> On Tue, Mar 10, 2015 at 7:37 AM, Nux!  wrote:
>> Agreed.
>> 
>> One more RC, please, David?
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
>> - Original Message -
>>> From: "Abhinandan Prateek" 
>>> To: dev@cloudstack.apache.org
>>> Sent: Tuesday, 10 March, 2015 11:31:40
>>> Subject: Re: ACS 4.5 Release [URGENT]
>> 
 
 On 03/10/2015 11:45 AM, Geoff Higginbottom wrote:
> @PMC
> 
> Whilst the Vote has officially passed, we have not announced it yet
> so still have time to retract the release, fix and then potentially
> re-vote etc.
> 
 
 This seems like a serious issue to me. Rules not applying on a VR is a
 big problem.
 
 We should release good software instead of broken versions, since that
 will damage the reputation of CloudStack.
>>> 
>>> I do agree here. We should fix it and then ship.
>>> 
 
 Wido
 
> Regards
> 
> Geoff Higginbottom
> 
> D: +44 20 3603 0542 | S: +44 20 3603
> 0540 | M: +447968161581
> 
> geoff.higginbot...@shapeblue.com
> 
> From: Paul Angus [mailto:paul.an...@shapeblue.com] Sent: 10 March
> 2015 10:28 To: dev@cloudstack.apache.org Subject: ACS 4.5 Release
> [URGENT] Importance: High
> 
> Hi All,
> 
> Given that the release 4.5 vote passed, with the blocker
> https://issues.apache.org/jira/browse/CLOUDSTACK-8248 which had the
> knock on effect of
> CLOUDSTACK-8305
> 
> 
> 
> VPC ACL Rules are not applied to Virtual
> Router
> 
> Do we have a mechanism to recall/annul that RC vote and use a build
> with the fixes in?  I have a horrible feeling that it would require
> another round of voting, but that has to be better than shipping a
> broken product.
> 
> 
> 
> Regards
> 
> Paul Angus Cloud Architect
> 
> [cid:image001.png@01D01549.640501B0]
> 
> D: +44 20 3468 5163 |S: +44 20 3603
> 0540 | M: +44 7711 418 784 |
> T: @CloudyAngus
> paul.an...@shapeblue.com |
> www.shapeblue.com |
> Twitter:@shapeblue ShapeBlue Ltd, 53 Chandos
> Place, Covent Garden, London, WC2N 4HS
> 
> Find out more about ShapeBlue and our range of CloudStack related
> services
> 
> IaaS Cloud Design &
> Build CSForge -
> rapid IaaS deployment framework
> CloudStack
> Consulting CloudStack
> Software
> Engineering
> CloudStack Infrastructure
> Support
> CloudStack Bootcamp Training
> Courses
> 
> This email and any attachments to it may be confidential and are
> intended solely for the use of the individual to whom it is
> addressed. Any views or opinions expressed are solely those of the
> author and do not necessarily represent those of Shape Blue Ltd or
> related companies. If you are not the intended recipient of this
> email, you must neither take any action based upon its contents,
> nor copy or show it to anyone. Please contact the sender if you
> believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India
> LLP is a company incorporated in India and is operated under
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
> a company incorporated in Brasil and is operated under license from
> Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The
> Republic of South Africa and is traded under license from Shape
> Blue Ltd. ShapeBlue is a registered trademark. Find out more about
> ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design &
> Build CSForge -
> rapid IaaS deployment framework
> CloudStack
> Consulting CloudStack
> Software
> Engineering
> CloudStack Infrastructure
> Support

Re: New SSL vulnerability #FREAK

[John Kinsella]

Thanks for confirmation, Eric

Pardon any typos - sent from mobile device
Stratosec
o: 415.315.9385
@johnlkinsella

On Mar 3, 2015, at 10:59 PM, Erik Weber 
mailto:terbol...@gmail.com>> wrote:

On Wed, Mar 4, 2015 at 2:21 AM, Nux! mailto:n...@li.nux.ro>> 
wrote:

https://freakattack.com/

That time of the month again. Secure your stuff, folks.


Tried against the SSVM on a CCP 4.3.2 installation, with updated system vm
template (think it was Beast or shellshock).
Does not export the mentioned ciphers.

--
Erik

Re: New SSL vulnerability #FREAK

[John Kinsella]

Pardon any typos - sent from mobile device
Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

On Mar 3, 2015, at 10:59 PM, Erik Weber 
mailto:terbol...@gmail.com>> wrote:

On Wed, Mar 4, 2015 at 2:21 AM, Nux! mailto:n...@li.nux.ro>> 
wrote:

https://freakattack.com/

That time of the month again. Secure your stuff, folks.


Tried against the SSVM on a CCP 4.3.2 installation, with updated system vm
template (think it was Beast or shellshock).
Does not export the mentioned ciphers.

--
Erik

Re: New SSL vulnerability #FREAK

[John Kinsella]

I don't *think* ACS is vulnerable, but haven't gotten a chance to confirm that 
yet. 

Excuse any typos - sent from mobile device

> On Mar 3, 2015, at 17:23, Nux!  wrote:
> 
> https://freakattack.com/
> 
> That time of the month again. Secure your stuff, folks.
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: [32/50] [abbrv] git commit: updated refs/heads/feature/systemvm-persistent-config to 4fe7264

[John Kinsella]

Would be nice if we weren’t setting a static VRRP password...

John

> On Feb 4, 2015, at 12:28 PM, d...@apache.org wrote:
> 
> Fix router priuority using the same logic as the one for the state
> Fix the router state. do not show UNKNOW, but MASTER or BACKUP depending on 
> the type of router
> Implement the virtual_router_id to be passed as a boot parameter to the router
>  - it is needed for the keepalived configuration
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/5303d2a8
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/5303d2a8
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/5303d2a8
> 
> Branch: refs/heads/feature/systemvm-persistent-config
> Commit: 5303d2a8e4ccd34d518c7e529d3ebd95e2933808
> Parents: cc384ee
> Author: wilderrodrigues 
> Authored: Tue Jan 27 14:05:38 2015 +0100
> Committer: wilderrodrigues 
> Committed: Wed Feb 4 18:47:09 2015 +0100
> 
> --
> .../VirtualNetworkApplianceManagerImpl.java | 22 +---
> .../debian/config/opt/cloud/bin/cs/CsDatabag.py |  7 ++-
> .../config/opt/cloud/bin/cs/CsRedundant.py  |  3 ++-
> .../opt/cloud/templates/keepalived.conf.templ   |  4 ++--
> 4 files changed, 24 insertions(+), 12 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/5303d2a8/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
> --
> diff --git 
> a/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> b/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
> index f0730f5..1c32c7e 100644
> --- 
> a/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
> +++ 
> b/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
> @@ -1302,23 +1302,24 @@ Configurable, StateListener VirtualMachine.Event, VirtualMachine> {
> }
> }
> 
> -protected int getUpdatedPriority(final Network network, final 
> List routers, final DomainRouterVO exclude)
> +protected int getUpdatedPriority(final Network network, final 
> List routers, final DomainRouterVO masterRouter)
> throws InsufficientVirtualNetworkCapacityException {
> int priority;
> if (routers.size() == 0) {
> priority = DEFAULT_PRIORITY;
> } else {
> int maxPriority = 0;
> -for (final DomainRouterVO r : routers) {
> -if (!r.getIsRedundantRouter()) {
> +
> +final DomainRouterVO router0 = routers.get(0);
> +if (router0.getId() == masterRouter.getId()) {
> +if (!router0.getIsRedundantRouter()) {
> throw new CloudRuntimeException("Redundant router is 
> mixed with single router in one network!");
> }
> -// FIXME Assume the maxPriority one should be running or just
> -// created.
> -if (r.getId() != exclude.getId() && 
> _nwHelper.getRealPriority(r) > maxPriority) {
> -maxPriority = _nwHelper.getRealPriority(r);
> -}
> +maxPriority = _nwHelper.getRealPriority(router0);
> +} else {
> +maxPriority = DEFAULT_PRIORITY;
> }
> +
> if (maxPriority == 0) {
> return DEFAULT_PRIORITY;
> }
> @@ -1330,6 +1331,7 @@ Configurable, StateListener VirtualMachine.Event, VirtualMachine> {
> throw new InsufficientVirtualNetworkCapacityException("Too 
> many times fail-over happened! Current maximum priority is too high as " + 
> maxPriority + "!",
> network.getId());
> }
> +
> priority = maxPriority - DEFAULT_DELTA + 1;
> }
> return priority;
> @@ -1589,6 +1591,7 @@ Configurable, StateListener VirtualMachine.Event, VirtualMachine> {
> final boolean isRedundant = router.getIsRedundantRouter();
> if (isRedundant) {
> buf.append(" redundant_router=1");
> +buf.append(" router_id=").append(router.getId());
> 
> final Long vpcId = router.getVpcId();
> final List routers;
> @@ -1599,13 +1602,16 @@ Configurable, StateListener VirtualMachine.Event, VirtualMachine> {
> }
> 
> String redundantState = RedundantState.BACKUP.toString();
> +router.setRedundantState(RedundantState.BACKUP);
> if (routers.size() == 0) {
> redundantState = RedundantState.MASTER.toString();
> +router.setRedundantState(RedundantState.MASTER);
> } else {
> final DomainRouterVO router0 = routers.get(0);
> 
> if (rou

Re: [DISCUSS] we need a better SSVM solution

[John Kinsella]

Decent points. You think the difference between the VR/CP is different enough 
to have a second image?

> On Jan 29, 2015, at 1:41 PM, Paul Angus  wrote:
> 
> Hi All,
> 
> I think that there are 3 things people would like to see:
> 
> 1. clear versioning of system vm templates, with some kind of compatibility 
> matrix so they know which one(s) they can use with different versions of 
> CloudStack
> 2. an easy way to update the system vm template
> 3. an easy(ish) way to customise system vm templates
> 
> It might be worth considering have two types of template
> a. the console proxy and secondary storage template
> b. the virtual router/ VPC template.
> 
> 
> 
> Regards
> 
> Paul Angus
> Cloud Architect
> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
> paul.an...@shapeblue.com
> 
> -Original Message-
> From: John Kinsella [mailto:j...@stratosec.co]
> Sent: 29 January 2015 18:06
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] we need a better SSVM solution
> 
> Interesting…
> 
> Concur on having an open/standardized protocol. Something clustered like 
> Serf/Consul could be attractive, but the overhead/requirements of those type 
> of things usually scares me away.
> 
> Having ACS act as a CA would be quite interesting for some things. It’s one 
> of the reasons I’ve pondered a “hook” in the past to notify 3rd party upon VM 
> creation/deletion/etc. Wonder if we could take advantage of dogtag or 
> similar. All that said - setup/management of a CA is a PIA and probably 
> outside scope of ACS, unless you did a “light” one similar to Puppet by 
> default...
> 
> An aside on that “hook” idea - something scriptable similar to (I said 
> “similar to," no flames!) systemd for this could be interesting.
> 
> A good portion of users would resist having an agent installed on the user 
> VM, but I guess we’re in that position already, and they just wouldn’t get 
> the added functionality.
> 
> One user experience point: Almost every time Parallels comes out with a new 
> version, I have to update their agent on my VMs, which on the Windows side 
> means a reboot. That gets old, and I’ve only got a handful of win VMs there...
> 
> Going to see if I can puppet-ize one of the SSVMs over the weekend to see 
> what other thoughts come up.
> 
> John
> 
>> On Jan 29, 2015, at 2:06 AM, Rohit Yadav  wrote:
>> 
>> Good ideas John.
>> 
>> I’m in fact already discussing a design I’m calling it "agents framework” 
>> (suggestions for better name are welcome!), I will try to share and update 
>> the spec soon that aims for this feature and refactoring work for ACS 
>> 4.6/master. For now, I’ve shared an architecture diagram here and some high 
>> level goals:
>> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework
>> 
>> Along with this, I’ve strong opinions and interests in just getting rid of 
>> Java based agents in systemvms (to reduce memory footprint) and replace the 
>> current agent-management server protocol (TCP based, which connects to only 
>> one management server on prt 8250 even if there are multiple management 
>> servers) with some interoperable protocol such as json/http, thrift etc that 
>> allows us to build better/scalable console proxy services (for example). 
>> People don’t discuss much, but virtual routers and systemvms are not well 
>> tested at all, we should also need efforts/infra to test these components 
>> with less human QA.
>> 
>> Regards.
>> 
>>> On 29-Jan-2015, at 2:14 am, John Kinsella  wrote:
>>> 
>>> Every time there’s an issue (security or otherwise) with the system VM 
>>> ISOs, it’s a relative pain to fix. They’re sort of a closed system, people 
>>> know little (relative to other ACS parts, IMHO) about their innards, and 
>>> updating them is more difficult than it should be.
>>> 
>>> I’d love to see a Better Way. I think these things could be dynamically 
>>> built, with the option to have them connect to a configuration management 
>>> (CM) system such as Puppet, Chef, Salt-Stack or whatever else floats 
>>> people’s boat.
>>> 
>>> One possible use case:
>>> * User installs new ACS system.
>>> * User logs into mgmt server, goes to Templates area, clicks button to 
>>> fetch default SSVM image. UI allows providing alternative URL, other 
>>> options as needed.
>>> * (time passes)
>>> * Security issue is announced. User goes back into Templates area, selects 
>>> SSVM template, clicks “Download updated template” and it does. U

Re: [DISCUSS] we need a better SSVM solution

[John Kinsella]

Interesting…

Concur on having an open/standardized protocol. Something clustered like 
Serf/Consul could be attractive, but the overhead/requirements of those type of 
things usually scares me away.

Having ACS act as a CA would be quite interesting for some things. It’s one of 
the reasons I’ve pondered a “hook” in the past to notify 3rd party upon VM 
creation/deletion/etc. Wonder if we could take advantage of dogtag or similar. 
All that said - setup/management of a CA is a PIA and probably outside scope of 
ACS, unless you did a “light” one similar to Puppet by default...

An aside on that “hook” idea - something scriptable similar to (I said “similar 
to," no flames!) systemd for this could be interesting.

A good portion of users would resist having an agent installed on the user VM, 
but I guess we’re in that position already, and they just wouldn’t get the 
added functionality.

One user experience point: Almost every time Parallels comes out with a new 
version, I have to update their agent on my VMs, which on the Windows side 
means a reboot. That gets old, and I’ve only got a handful of win VMs there...

Going to see if I can puppet-ize one of the SSVMs over the weekend to see what 
other thoughts come up.

John

> On Jan 29, 2015, at 2:06 AM, Rohit Yadav  wrote:
> 
> Good ideas John.
> 
> I’m in fact already discussing a design I’m calling it "agents framework” 
> (suggestions for better name are welcome!), I will try to share and update 
> the spec soon that aims for this feature and refactoring work for ACS 
> 4.6/master. For now, I’ve shared an architecture diagram here and some high 
> level goals:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework
> 
> Along with this, I’ve strong opinions and interests in just getting rid of 
> Java based agents in systemvms (to reduce memory footprint) and replace the 
> current agent-management server protocol (TCP based, which connects to only 
> one management server on prt 8250 even if there are multiple management 
> servers) with some interoperable protocol such as json/http, thrift etc that 
> allows us to build better/scalable console proxy services (for example). 
> People don’t discuss much, but virtual routers and systemvms are not well 
> tested at all, we should also need efforts/infra to test these components 
> with less human QA.
> 
> Regards.
> 
>> On 29-Jan-2015, at 2:14 am, John Kinsella  wrote:
>> 
>> Every time there’s an issue (security or otherwise) with the system VM ISOs, 
>> it’s a relative pain to fix. They’re sort of a closed system, people know 
>> little (relative to other ACS parts, IMHO) about their innards, and updating 
>> them is more difficult than it should be.
>> 
>> I’d love to see a Better Way. I think these things could be dynamically 
>> built, with the option to have them connect to a configuration management 
>> (CM) system such as Puppet, Chef, Salt-Stack or whatever else floats 
>> people’s boat.
>> 
>> One possible use case:
>> * User installs new ACS system.
>> * User logs into mgmt server, goes to Templates area, clicks button to fetch 
>> default SSVM image. UI allows providing alternative URL, other options as 
>> needed.
>> * (time passes)
>> * Security issue is announced. User goes back into Templates area, selects 
>> SSVM template, clicks “Download updated template” and it does. Under 
>> infrastructure/system VMs and infrastrucutre/virtual routers, there’s 
>> buttons to update one or more running instances to use the new template
>> 
>> Another possible use case:
>> * User installs new ACS system
>> * User uploads SSVM template that has CM agent configured to talk to their 
>> CM server (I’ve been wanting to lab this for a while now)
>> * As ACS creates system VMs, they phone home to CM server, it provides them 
>> with instructions to install various packages and config as needed to be 
>> domr/console proxy/whatever. We provide basic “recipes” for CM systems for 
>> people to use and grow from.
>> * Security issue is announced. User updates recipe in CM system, a few 
>> minutes later the SSVMs are up-to-date.
>> 
>> Modification on that use case: We ship the SSVM with puppet/chef/blah 
>> installed, part of the SSVM “patch” process configures appropriate CM system.
>> 
>> What might make the second use case easier would be to have some hooks in 
>> ACS that when a system is created/destroyed/modified, it informs 3rd party 
>> via API.
>> 
>> (Obviously API calls for all of the above to allow process without touching 
>> the UI)
>> 
>> Thoughts?
>> 
>> John
> 
> Regards,
> Rohit Yadav
> Sof

Re: Ghost glibc vulnerability and CloudStack

[John Kinsella]

https://blogs.apache.org/cloudstack/entry/cloudstack_and_the_ghost_glibc has 
now been updated with links to download the updated SSVM

John

On Jan 28, 2015, at 11:55 AM, John Kinsella 
mailto:j...@stratosec.co>> wrote:

There’s a new vulnerability out in most Linux distributions that has potential 
to be fairly severe. As it affects most Linux distributions, we’re putting 
mitigation steps out immediately at [1].

This affects many Linux distributions, so please review management servers, 
databases, storage systems, etc.

An updated SSVM template is being QAed, once released the post will be updated 
with links and we’ll mention here as well.

John
1: https://blogs.apache.org/cloudstack/entry/cloudstack_and_the_ghost_glibc

[DISCUSS] we need a better SSVM solution

[John Kinsella]

Every time there’s an issue (security or otherwise) with the system VM ISOs, 
it’s a relative pain to fix. They’re sort of a closed system, people know 
little (relative to other ACS parts, IMHO) about their innards, and updating 
them is more difficult than it should be.

I’d love to see a Better Way. I think these things could be dynamically built, 
with the option to have them connect to a configuration management (CM) system 
such as Puppet, Chef, Salt-Stack or whatever else floats people’s boat.

One possible use case:
* User installs new ACS system.
* User logs into mgmt server, goes to Templates area, clicks button to fetch 
default SSVM image. UI allows providing alternative URL, other options as 
needed.
* (time passes)
* Security issue is announced. User goes back into Templates area, selects SSVM 
template, clicks “Download updated template” and it does. Under 
infrastructure/system VMs and infrastrucutre/virtual routers, there’s buttons 
to update one or more running instances to use the new template

Another possible use case:
* User installs new ACS system
* User uploads SSVM template that has CM agent configured to talk to their CM 
server (I’ve been wanting to lab this for a while now)
* As ACS creates system VMs, they phone home to CM server, it provides them 
with instructions to install various packages and config as needed to be 
domr/console proxy/whatever. We provide basic “recipes” for CM systems for 
people to use and grow from.
* Security issue is announced. User updates recipe in CM system, a few minutes 
later the SSVMs are up-to-date.

Modification on that use case: We ship the SSVM with puppet/chef/blah 
installed, part of the SSVM “patch” process configures appropriate CM system.

What might make the second use case easier would be to have some hooks in ACS 
that when a system is created/destroyed/modified, it informs 3rd party via API.

(Obviously API calls for all of the above to allow process without touching the 
UI)

Thoughts? 

John

Ghost glibc vulnerability and CloudStack

[John Kinsella]

There’s a new vulnerability out in most Linux distributions that has potential 
to be fairly severe. As it affects most Linux distributions, we’re putting 
mitigation steps out immediately at [1].

This affects many Linux distributions, so please review management servers, 
databases, storage systems, etc.

An updated SSVM template is being QAed, once released the post will be updated 
with links and we’ll mention here as well.

John
1: https://blogs.apache.org/cloudstack/entry/cloudstack_and_the_ghost_glibc

Reminder: potential security issues

[John Kinsella]

Everyone - we’ve[1] noticed a commit recently that's related to improving the 
security of CloudStack (I’m referring to the timing attack commit).

We love seeing folks have an interest in the security of CloudStack - the one 
request we make is if you your work improves the security of ACS or patches a 
potential security vulnerability, shoot 
secur...@cloudstack.apache.org a quick 
note before you commit, submit code for review, or submit a pull request. We’ll 
take a quick peek and let you know if we’re OK with you continuing with your 
thing, or if we want to treat it as a formal security issue and run through the 
process at [2]. I do watch the commits and scan for a collection of keywords 
that could indicate issues, but would rather catch issues before they’re public.

Thanks for all your efforts!

John
1: (The secur...@cloudstack.apache.org 
“we”)
2: https://cloudstack.apache.org/security.html

ps for the record, I’m not really worried about somebody leveraging a timing 
attack vulnerability so not too concerned about this case.

Re: pnfs support?

[John Kinsella]

I’m a little surprised we don’t see more mentions of Lustre et al in the IaaS 
space, but I guess the HPC crowd don’t want hypervisors getting in the way.

Personally I’m quite happy with kvm+rbd. CephFS sounds nice but I can only hold 
my breath for so long...

Anyways - seems easy to add support ("-o minorversion=1”)[1] but it’s not clear 
to me how to tell the minor version the server’s running - looks like nfsstat 
only reports major version?

1: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch09s02.html

> On Jan 14, 2015, at 11:59 PM, Sebastien Goasguen  wrote:
> 
> pNFS is more in the Lustre, GPFS landscape, supposed to be a real parallel 
> file system with all posix semantics supported.
> 
> ..but I never used it…
> 
> everyone has been waiting on CephFS :)
> 
> On Jan 14, 2015, at 10:38 PM, John Kinsella  wrote:
> 
>> Somebody in the silicon valley meetup just asked about pNFS [1] - I’d never 
>> heard of it, but sounds interesting and in theory would negate a lot of the 
>> ugliness of NFS.
>> 
>> Curious if anybody else is familiar with it, or if there’s a general 
>> interest in having support in ACS?
>> 
>> John
>> 1: http://www.pnfs.com/
> 

pnfs support?

[John Kinsella]

Somebody in the silicon valley meetup just asked about pNFS [1] - I’d never 
heard of it, but sounds interesting and in theory would negate a lot of the 
ugliness of NFS.

Curious if anybody else is familiar with it, or if there’s a general interest 
in having support in ACS?

John
1: http://www.pnfs.com/

Upgrade your git clients

[John Kinsella]

Folks - just heard of a vulnerability in apparently all git clients where if 
you’re using a case-insensitive filesystem (e.g. Windows or OSX), somebody 
could overwrite your .git/config directory, resulting in running commands on 
your local box.

Short story, upgrade your git clients.

More info here:
https://github.com/blog/1938-git-client-vulnerability-announced

John

Re: [DISCUSS] Issues with Ubuntu instance creation

[John Kinsella]

> On Dec 8, 2014, at 8:10 AM, Tim Mackey  wrote:
> 
> I've been working through a series of issues getting Ubuntu 12.04 LTS 
> templates to provision correctly, and I *think* most are really doc issues, 
> but before I run off and update docs I wanted to confirm that I'm doing the 
> right thing.  Here's my list of issues, and what I did to get past my 
> "issue".  My documentation source is: 
> http://cloudstack-administration.readthedocs.org/en/latest/templates.html.  
> My CloudStack is 4.4.
> 
> 1. The docs make no mention of an Ubuntu change password script, and Google 
> returns Shankar's GitHub scripts as option #4.  Unfortunately, that script 
> has a user of "ubuntu" hardcoded into it, so unless your template has an 
> "ubuntu" user, its not going to work.  I haven't tried to use the stock 
> CloudStack password change script in my template, but have found references 
> to it not working as expected.  For my purposes, I changed Shankar's script 
> to use a "root" user, but this leaves the following questions open:
> 
> - Does the current CloudStack script work with Ubuntu 12.04 and later?  If 
> so, I vote the docs be updated to reflect support for Ubuntu 12.04 and later; 
> with the objective of both clarifying the docs and helping boost our docs to 
> a higher rank than Shankar's GitHub.

See [1]. It should work with 12.04LTS.

> - If the current CloudStack script doesn't work with Ubuntu 12.04 LTS, should 
> a JIRA ticket be entered to resolve this, or should we have multiple scripts 
> available and effectively incorporate Shankar's work more officially?
> 
> 2. The docs recommend setting the password to expire, but when the change 
> password script runs, that flag is cleared and the user isn't promoted to 
> reset the root password.  That leaves the following question in my mind.  
> 
> - Is our password intended to be a one-time use password.  If so, then the 
> password change script should reset expiration forcing a new one to be set.  
> If not, then should we not remove the "expire password" recommendation from 
> the docs?

Some providers and cloud mgmt platforms keep a copy of the “current” root 
password as set by the reset script. That type of functionality is why there’s 
probably no “expire” in the change passed script. I think you confusion is 
coming from the template section is not closely tied to the password management 
section - if one is making templates, they should reset the password so first 
login requires new password. This saves us from having thousands of VMs on the 
Internet with a default password. If a shop is making templates, and using 
password management - the password should be generated at VM creation and 
shouldn’t be an issue.

Either way - you really shouldn’t be logging into systems (VMs or physical) as 
root on a regular basis.

> 3. The script in the docs covering clearing the logs (step 6) doesn't include 
> clearing syslog.  Recommend updating the script to include:  cat /dev/null > 
> /var/log/syslog 2>/dev/null
> 
> 4. The script in the docs covering clearing of command history (step 9) 
> doesn't clear the in memory history.  Recommend updating the script to 
> become:  cat /dev/null > ~/.bash_history && history -c && unset HISTFILE && 
> halt -p.  This would also remove the the shutdown step (step 10).

Good points, although I’m not sure if “halt” is as safe as shutdown...

> 5. The script to set the hostname has a race condition which effectively 
> means it rarely sets the hostname correctly on initial boot.  I've attached 
> the script I used.  It doesn't depend upon the leases file being present, and 
> took care of some alternate "blank" hostname cases I encountered while 
> debugging.

Unfortunately ASF lists strip out attachments. 

> I'm happy to update the docs, but want to make certain what I've encountered 
> as issues are things we care about updating.

Would love to have your changes. At the minimum, please create Jira tickets, 
but if/where possible we’d happily take either submitted code review requests 
or pull requests on github.

John

1: 
http://cloudstack-administration.readthedocs.org/en/latest/templates.html#adding-password-management-to-your-templates

[CVE-2014-7807] Apache CloudStack unauthenticated LDAP binds

[John Kinsella]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

CVE-2014-7807: Apache CloudStack unauthenticated LDAP binds

CVSS:
7.5, AV:N/AC:L/Au:N/C:P/I:P/A:P

Vendors:
The Apache Software Foundation
Citrix, Inc.

Versions Afffected:
Apache CloudStack 4.3, 4.4

Description:
Apache CloudStack may be configured to authenticate LDAP users.
When so configured, it performs a simple LDAP bind with the name
and password provided by a user.  Simple LDAP binds are defined
with three mechanisms (RFC 4513): 1) username and password; 2)
unauthenticated if only a username is specified; and 3) anonymous
if neither username or password is specified.  Currently, Apache
CloudStack does not check if the password was provided which could
allow an attacker to bind as an unauthenticated user.

Mitigation:
Users of Apache CloudStack 4.4 and derivatives should update to the
latest version (4.4.2)

An updated release for Apache CloudStack 4.3.2 is in testing. Until
that is released, we recommend following the mitigation below:

By default, many LDAP servers are not configured to allow unauthenticated
binds.  If the LDAP server in use allow this behaviour, a potential
interim solution would be to consider disabling unauthenticated
binds.

Credit:
This issue was identified by the Citrix Security Team.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCgAGBQJUhgUCAAoJEOom9N0pCN7SOQMQAKyBuhg25u3FcVOU5XMdGGpT
2kSVFoLFR74ObI8bdr3HP+2LdLf/Go9QBBrWlZ034FUj6OV0Ct5o8TNB6AHbv0qF
Ar4N05JoGtPaDCe9sWV/+ykOJH8snQjnYwVFrLZlLw8Y/JUQ+I1yJBksw8a2/hT2
vmYgYiAQyrEMMk4bhBBlEyaJFMhuMtKtgUqLDW8wmlhkt2acZMt/0BKxDwAO8o7m
6ypepPCmkPHUpD50tfcCI+K4ib/C5EOn40n4orM97/JHZLsCyhz5nk36eQMOQQz2
fJlaA04fQSV4Cv7c+S0LPh5e4e6TPSrOW3O4/V2dkjK/GgP8kUoo7ivyjIw6d2oJ
Z5vqqgxrmgwDjH58YfVu3tyVuDlOFTZfCLkhdoXMxHfMLYYKeXkffRli9XabxrE+
AkVoXaQAumf8IzTLVSQztV18jC79kvEeCV0pFYOjb/X/gShemruqmCWVDulj1ax6
tzoP+Bm2mQRyrRClY37R+q3cQ2z6eNAC/vAoYzhYBN1o63MYneLYDADhyE6YIGz0
LTbDDGFn0WVdFDrqworHdYDIMW7HQFMNtsQuueeP7LBldsgyTmjmBMp+S3Tq27UT
RaVgp3n9ZUPdzj/i1vvJBrATKUNmv1GDoy+C1GPNx423nEOe7dFkMJARlcbf5Pml
03DX+ot4Xan0P5HXPT+r
=QqOf
-END PGP SIGNATURE-

Re: A secure way to reset VMs password

[John Kinsella]

Decent idea…

> On Dec 3, 2014, at 8:24 AM, Alireza Eskandari 
>  wrote:
> 
> It is possible if we provide password service on port 8080 with current 
> insecure method and on port 8443 with secure method.
> with this solution we can use both old and new password reset service.
> 
>  Original message 
> From: Logan Barfield  
> Date: 03/12/2014  19:32  (GMT+03:30) 
> To: dev@cloudstack.apache.org 
> Subject: Re: A secure way to reset VMs password 
> 
> Passwords are most definitely a necessity, but not having SSH Keys in the
> GUI at this point just doesn't make any sense.
> 
> To clarify my thoughts on the current password system: I think a re-write
> would be great, but it should include an "insecure/legacy" option (probably
> as a global setting) that would continue to function with the current reset
> scripts.
> 
> 
> Thank You,
> 
> Logan Barfield
> Tranquil Hosting
> 
> On Wed, Dec 3, 2014 at 10:55 AM, Andrija Panic 
> wrote:
> 
>> +1 what Nux said - I'm aware of many web developers NOT knowing what the
>> SSH keys are at all, and thus not using them... most of them relly on
>> passwords... but nice to have ssh keys for rest of us.
>> 
>> On 3 December 2014 at 16:52, Nux!  wrote:
>> 
>>> Keys are not for everyone. Passwords are still used a lot.
>>> 
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> 
>>> Nux!
>>> www.nux.ro
>>> 
>>> - Original Message -
>>>> From: "Carlos Reategui" 
>>>> To: dev@cloudstack.apache.org
>>>> Sent: Wednesday, 3 December, 2014 05:19:07
>>>> Subject: Re: A secure way to reset VMs password
>>> 
>>>> Why do passwords at all?  Why not just use ssh keys like AWS does. The
>>>> functionality is already there just not in the ACS UI. Cloud-init
>> already
>>>> supports it which is available in most distros and therefore would not
>>> require
>>>> CS specific scripts. At least not for linux. On windows I'm not exactly
>>> sure
>>>> how AWS does it but I think it is also some kind of terminal services
>>>> certificates so I think it could be made to work too.
>>>> 
>>>> -Carlos
>>>> 
>>>> 
>>>> 
>>>>> On Dec 2, 2014, at 2:35 PM, Chiradeep Vittal <
>>> chiradeep.vit...@citrix.com>
>>>>> wrote:
>>>>> 
>>>>> You would need client-side certs as well since the password server
>>> needs to be
>>>>> able to validate WHO is asking for the password. Currently it is based
>>> on the
>>>>> client's IP address.
>>>>> Also the current scheme is a single-use password — as soon as the
>>> password is
>>>>> retrieved, it is not available to anybody else (of course a MITM could
>>> sniff
>>>>> the first exchange).
>>>>> 
>>>>> You could eliminate a lot of MITM-style attacks by running the
>> password
>>> server
>>>>> locally on each hypervisor (hard for VMW), or by attaching an ISO
>>> (containing
>>>>> the password) to the VM.
>>>>> 
>>>>> From: John Kinsella mailto:j...@stratosec.co>>
>>>>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org
>>> "
>>>>> mailto:dev@cloudstack.apache.org>>
>>>>> Date: Tuesday, December 2, 2014 at 1:32 PM
>>>>> To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
>>>>> mailto:dev@cloudstack.apache.org>>
>>>>> Subject: Re: A secure way to reset VMs password
>>>>> 
>>>>> That password reset infrastructure has bigger issues than just SSL.
>> The
>>> server
>>>>> side works, but that’s about all I can say for it. This topic comes up
>>> every
>>>>> 6-12 months. :)
>>>>> 
>>>>> I thought there was a Jira entry but I can’t find it…personally I’d
>>> love to see
>>>>> the client and server sides both rewritten from scratch.
>>>>> 
>>>>> John
>>>>> 
>>>>> On Nov 28, 2014, at 11:33 AM, Nux! > n...@li.nux.ro>>
>>> wrote:
>>>>> Jayapal,
>>>>> Not necesarily, one could run stunnel or nginx as SSL proxy on some
>>> other port
>>>>> (8443?), t

Re: A secure way to reset VMs password

[John Kinsella]

Probably should be re-written. 

Excuse any typos - sent from mobile device

> On Dec 2, 2014, at 21:58, Alireza Eskandari  
> wrote:
> 
> John, +1If we provide password reset capability it should be secure, if not 
> it is better to make it disable at all.About source of windows version, so 
> what did we do? Should we write it from scratch? Why it isn't open?I open a 
> jira ticket, if you have any comment or suggestion please write 
> there.https://issues.apache.org/jira/browse/CLOUDSTACK-8009
> Thanks
>  From: John Kinsella 
> To: ""  
> Sent: Wednesday, December 3, 2014 9:18 AM
> Subject: Re: A secure way to reset VMs password
> 
> It's not our place to enforce how users authenticate to their VMs. We provide 
> flexible options, suggest best practices, and let them use the tool as best 
> suits their needs.
> 
> Excuse any typos - sent from mobile device
> 
> 
> 
>> On Dec 2, 2014, at 21:22, Carlos Reategui  wrote:
>> 
>> Why do passwords at all?  Why not just use ssh keys like AWS does. The 
>> functionality is already there just not in the ACS UI. Cloud-init already 
>> supports it which is available in most distros and therefore would not 
>> require CS specific scripts. At least not for linux. On windows I'm not 
>> exactly sure how AWS does it but I think it is also some kind of terminal 
>> services certificates so I think it could be made to work too. 
>> 
>> -Carlos
>> 
>> 
>> 
>>> On Dec 2, 2014, at 2:35 PM, Chiradeep Vittal  
>>> wrote:
>>> 
>>> You would need client-side certs as well since the password server needs to 
>>> be able to validate WHO is asking for the password. Currently it is based 
>>> on the client's IP address.
>>> Also the current scheme is a single-use password — as soon as the password 
>>> is retrieved, it is not available to anybody else (of course a MITM could 
>>> sniff the first exchange).
>>> 
>>> You could eliminate a lot of MITM-style attacks by running the password 
>>> server locally on each hypervisor (hard for VMW), or by attaching an ISO 
>>> (containing the password) to the VM.
>>> 
>>> From: John Kinsella mailto:j...@stratosec.co>>
>>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
>>> mailto:dev@cloudstack.apache.org>>
>>> Date: Tuesday, December 2, 2014 at 1:32 PM
>>> To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
>>> mailto:dev@cloudstack.apache.org>>
>>> Subject: Re: A secure way to reset VMs password
>>> 
>>> That password reset infrastructure has bigger issues than just SSL. The 
>>> server side works, but that’s about all I can say for it. This topic comes 
>>> up every 6-12 months. :)
>>> 
>>> I thought there was a Jira entry but I can’t find it…personally I’d love to 
>>> see the client and server sides both rewritten from scratch.
>>> 
>>> John
>>> 
>>> On Nov 28, 2014, at 11:33 AM, Nux! mailto:n...@li.nux.ro>> 
>>> wrote:
>>> Jayapal,
>>> Not necesarily, one could run stunnel or nginx as SSL proxy on some other 
>>> port (8443?), this way SSL and non-SSL connections will still work and give 
>>> you plenty of time to update your templates, if you so wish.
>>> Am I missing any important bits here?
>>> Lucian
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> Nux!
>>> www.nux.ro
>>> - Original Message -
>>> From: "Jayapal Reddy Uradi" 
>>> mailto:jayapalreddy.ur...@citrix.com>>
>>> To: "mailto:dev@cloudstack.apache.org>>" 
>>> mailto:dev@cloudstack.apache.org>>
>>> Cc: "Alireza Eskandari" 
>>> mailto:astro.alir...@yahoo.com>>
>>> Sent: Friday, 28 November, 2014 09:34:02
>>> Subject: Re: A secure way to reset VMs password
>>> Another point to note is all the vms in production has to update
>>> with the new cloud-set-guest-password scripts because of the new password 
>>> reset
>>> method.
>>> Thanks,
>>> Jayapal
>>> On 28-Nov-2014, at 2:28 PM, Erik Weber 
>>> mailto:terbol...@gmail.com>>
>>> wrote:
>>> On Thu, Nov 27, 2014 at 3:54 PM, Alireza Eskandari <
>>> astro.alir...@yahoo.com.invalid<mailto:astro.alir...@yahoo.com.invalid>> 
>>> wrote:
>>> HiI viewed the bash script that resets Linux password (

Re: A secure way to reset VMs password

[John Kinsella]

While they might be better than weak passwords, ssh keys are not a silver 
bullet - they're harder to use and a case can be made that they're no more 
secure (think: attacker compromises desktop, accesses ssh key file)

And no, from my previous research, you can't enforce that an ssh key has a 
passphrase...

Excuse any typos - sent from mobile device

> On Dec 2, 2014, at 22:01, Carlos Reátegui  wrote:
> 
> I’m all for providing choice, but not when one of them is not a good/secure 
> one.
> 
> 
>> On Dec 2, 2014, at 9:48 PM, John Kinsella  wrote:
>> 
>> It's not our place to enforce how users authenticate to their VMs. We 
>> provide flexible options, suggest best practices, and let them use the tool 
>> as best suits their needs.
>> 
>> Excuse any typos - sent from mobile device
>> 
>>> On Dec 2, 2014, at 21:22, Carlos Reategui  wrote:
>>> 
>>> Why do passwords at all?  Why not just use ssh keys like AWS does. The 
>>> functionality is already there just not in the ACS UI. Cloud-init already 
>>> supports it which is available in most distros and therefore would not 
>>> require CS specific scripts. At least not for linux. On windows I'm not 
>>> exactly sure how AWS does it but I think it is also some kind of terminal 
>>> services certificates so I think it could be made to work too. 
>>> 
>>> -Carlos
>>> 
>>> 
>>> 
>>>> On Dec 2, 2014, at 2:35 PM, Chiradeep Vittal  
>>>> wrote:
>>>> 
>>>> You would need client-side certs as well since the password server needs 
>>>> to be able to validate WHO is asking for the password. Currently it is 
>>>> based on the client's IP address.
>>>> Also the current scheme is a single-use password — as soon as the password 
>>>> is retrieved, it is not available to anybody else (of course a MITM could 
>>>> sniff the first exchange).
>>>> 
>>>> You could eliminate a lot of MITM-style attacks by running the password 
>>>> server locally on each hypervisor (hard for VMW), or by attaching an ISO 
>>>> (containing the password) to the VM.
>>>> 
>>>> From: John Kinsella mailto:j...@stratosec.co>>
>>>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
>>>> mailto:dev@cloudstack.apache.org>>
>>>> Date: Tuesday, December 2, 2014 at 1:32 PM
>>>> To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
>>>> mailto:dev@cloudstack.apache.org>>
>>>> Subject: Re: A secure way to reset VMs password
>>>> 
>>>> That password reset infrastructure has bigger issues than just SSL. The 
>>>> server side works, but that’s about all I can say for it. This topic comes 
>>>> up every 6-12 months. :)
>>>> 
>>>> I thought there was a Jira entry but I can’t find it…personally I’d love 
>>>> to see the client and server sides both rewritten from scratch.
>>>> 
>>>> John
>>>> 
>>>> On Nov 28, 2014, at 11:33 AM, Nux! mailto:n...@li.nux.ro>> 
>>>> wrote:
>>>> Jayapal,
>>>> Not necesarily, one could run stunnel or nginx as SSL proxy on some other 
>>>> port (8443?), this way SSL and non-SSL connections will still work and 
>>>> give you plenty of time to update your templates, if you so wish.
>>>> Am I missing any important bits here?
>>>> Lucian
>>>> --
>>>> Sent from the Delta quadrant using Borg technology!
>>>> Nux!
>>>> www.nux.ro
>>>> - Original Message -
>>>> From: "Jayapal Reddy Uradi" 
>>>> mailto:jayapalreddy.ur...@citrix.com>>
>>>> To: "mailto:dev@cloudstack.apache.org>>" 
>>>> mailto:dev@cloudstack.apache.org>>
>>>> Cc: "Alireza Eskandari" 
>>>> mailto:astro.alir...@yahoo.com>>
>>>> Sent: Friday, 28 November, 2014 09:34:02
>>>> Subject: Re: A secure way to reset VMs password
>>>> Another point to note is all the vms in production has to update
>>>> with the new cloud-set-guest-password scripts because of the new password 
>>>> reset
>>>> method.
>>>> Thanks,
>>>> Jayapal
>>>> On 28-Nov-2014, at 2:28 PM, Erik Weber 
>>>> mailto:terbol...@gmail.com>>
>>>> wrote:
>>>> On Thu, Nov 27, 2014 at 3:54 PM

Re: A secure way to reset VMs password

[John Kinsella]

It's not our place to enforce how users authenticate to their VMs. We provide 
flexible options, suggest best practices, and let them use the tool as best 
suits their needs.

Excuse any typos - sent from mobile device

> On Dec 2, 2014, at 21:22, Carlos Reategui  wrote:
> 
> Why do passwords at all?  Why not just use ssh keys like AWS does. The 
> functionality is already there just not in the ACS UI. Cloud-init already 
> supports it which is available in most distros and therefore would not 
> require CS specific scripts. At least not for linux. On windows I'm not 
> exactly sure how AWS does it but I think it is also some kind of terminal 
> services certificates so I think it could be made to work too. 
> 
> -Carlos
> 
> 
> 
>> On Dec 2, 2014, at 2:35 PM, Chiradeep Vittal  
>> wrote:
>> 
>> You would need client-side certs as well since the password server needs to 
>> be able to validate WHO is asking for the password. Currently it is based on 
>> the client's IP address.
>> Also the current scheme is a single-use password — as soon as the password 
>> is retrieved, it is not available to anybody else (of course a MITM could 
>> sniff the first exchange).
>> 
>> You could eliminate a lot of MITM-style attacks by running the password 
>> server locally on each hypervisor (hard for VMW), or by attaching an ISO 
>> (containing the password) to the VM.
>> 
>> From: John Kinsella mailto:j...@stratosec.co>>
>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
>> mailto:dev@cloudstack.apache.org>>
>> Date: Tuesday, December 2, 2014 at 1:32 PM
>> To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
>> mailto:dev@cloudstack.apache.org>>
>> Subject: Re: A secure way to reset VMs password
>> 
>> That password reset infrastructure has bigger issues than just SSL. The 
>> server side works, but that’s about all I can say for it. This topic comes 
>> up every 6-12 months. :)
>> 
>> I thought there was a Jira entry but I can’t find it…personally I’d love to 
>> see the client and server sides both rewritten from scratch.
>> 
>> John
>> 
>> On Nov 28, 2014, at 11:33 AM, Nux! mailto:n...@li.nux.ro>> 
>> wrote:
>> Jayapal,
>> Not necesarily, one could run stunnel or nginx as SSL proxy on some other 
>> port (8443?), this way SSL and non-SSL connections will still work and give 
>> you plenty of time to update your templates, if you so wish.
>> Am I missing any important bits here?
>> Lucian
>> --
>> Sent from the Delta quadrant using Borg technology!
>> Nux!
>> www.nux.ro
>> - Original Message -
>> From: "Jayapal Reddy Uradi" 
>> mailto:jayapalreddy.ur...@citrix.com>>
>> To: "mailto:dev@cloudstack.apache.org>>" 
>> mailto:dev@cloudstack.apache.org>>
>> Cc: "Alireza Eskandari" 
>> mailto:astro.alir...@yahoo.com>>
>> Sent: Friday, 28 November, 2014 09:34:02
>> Subject: Re: A secure way to reset VMs password
>> Another point to note is all the vms in production has to update
>> with the new cloud-set-guest-password scripts because of the new password 
>> reset
>> method.
>> Thanks,
>> Jayapal
>> On 28-Nov-2014, at 2:28 PM, Erik Weber 
>> mailto:terbol...@gmail.com>>
>> wrote:
>> On Thu, Nov 27, 2014 at 3:54 PM, Alireza Eskandari <
>> astro.alir...@yahoo.com.invalid<mailto:astro.alir...@yahoo.com.invalid>> 
>> wrote:
>> HiI viewed the bash script that resets Linux password (
>> http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in)It
>> seems that it doesn't use a secure way for transferring password string to
>> instance.Instances on a shared network can sniff password requests and
>> export requested password of other instances.I suggest to use SSL (https)
>> instead of plan text.Regards
>> I like the idea, but there's a couple of obstacles to overcome, namely
>> which SSL certificates to use.
>> - certificates need a subject name, ie. IP or hostname for web pages, you
>> could solve this by making the mgmt server a CA and have each VR get a
>> signed certificate by it, but it's complicated
>> - if the community bundle a pre generated certificate it is commonly known
>> and not to be trusted, also not sure how to handle subject name
>> - assuming everyone to supply a valid certificate is quite complicated (CA
>> must be on VR etc), and makes it considerably harder to get a working setup
>> - using self signed causes issues with validation
>> Don't get me wrong, I love the idea, but it's not just to flip a switch and
>> have (proper) SSL in place.
>> --
>> Erik
>> 
>> 

Re: A secure way to reset VMs password

[John Kinsella]

Correct...I've chatted with Folks in the past, it wasnt open-sourced.

Excuse any typos - sent from mobile device

> On Dec 2, 2014, at 20:50, Alireza Eskandari  
> wrote:
> 
> A stupid question!
> I can't find the source of windows version of password manager! Where is it?
> 
> Sent from Samsung Mobile.
> 
>  Original message From: Chiradeep Vittal 
>  Date:03/12/2014  02:05  (GMT+03:30) 
> To: dev@cloudstack.apache.org Subject: Re: A secure way 
> to reset VMs password 
> You would need client-side certs as well since the password server 
> needs to be able to validate WHO is asking for the password. Currently it is 
> based on the client's IP address.
> Also the current scheme is a single-use password — as soon as the password is 
> retrieved, it is not available to anybody else (of course a MITM could sniff 
> the first exchange).
> 
> You could eliminate a lot of MITM-style attacks by running the password 
> server locally on each hypervisor (hard for VMW), or by attaching an ISO 
> (containing the password) to the VM.
> 
> From: John Kinsella mailto:j...@stratosec.co>>
> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
> mailto:dev@cloudstack.apache.org>>
> Date: Tuesday, December 2, 2014 at 1:32 PM
> To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
> mailto:dev@cloudstack.apache.org>>
> Subject: Re: A secure way to reset VMs password
> 
> That password reset infrastructure has bigger issues than just SSL. The 
> server side works, but that’s about all I can say for it. This topic comes up 
> every 6-12 months. :)
> 
> I thought there was a Jira entry but I can’t find it…personally I’d love to 
> see the client and server sides both rewritten from scratch.
> 
> John
> 
> On Nov 28, 2014, at 11:33 AM, Nux! mailto:n...@li.nux.ro>> 
> wrote:
> Jayapal,
> Not necesarily, one could run stunnel or nginx as SSL proxy on some other 
> port (8443?), this way SSL and non-SSL connections will still work and give 
> you plenty of time to update your templates, if you so wish.
> Am I missing any important bits here?
> Lucian
> --
> Sent from the Delta quadrant using Borg technology!
> Nux!
> www.nux.ro
> - Original Message -
> From: "Jayapal Reddy Uradi" 
> mailto:jayapalreddy.ur...@citrix.com>>
> To: "mailto:dev@cloudstack.apache.org>>" 
> mailto:dev@cloudstack.apache.org>>
> Cc: "Alireza Eskandari" 
> mailto:astro.alir...@yahoo.com>>
> Sent: Friday, 28 November, 2014 09:34:02
> Subject: Re: A secure way to reset VMs password
> Another point to note is all the vms in production has to update
> with the new cloud-set-guest-password scripts because of the new password 
> reset
> method.
> Thanks,
> Jayapal
> On 28-Nov-2014, at 2:28 PM, Erik Weber 
> mailto:terbol...@gmail.com>>
> wrote:
> On Thu, Nov 27, 2014 at 3:54 PM, Alireza Eskandari <
> astro.alir...@yahoo.com.invalid<mailto:astro.alir...@yahoo.com.invalid>> 
> wrote:
> HiI viewed the bash script that resets Linux password (
> http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in)It
> seems that it doesn't use a secure way for transferring password string to
> instance.Instances on a shared network can sniff password requests and
> export requested password of other instances.I suggest to use SSL (https)
> instead of plan text.Regards
> I like the idea, but there's a couple of obstacles to overcome, namely
> which SSL certificates to use.
> - certificates need a subject name, ie. IP or hostname for web pages, you
> could solve this by making the mgmt server a CA and have each VR get a
> signed certificate by it, but it's complicated
> - if the community bundle a pre generated certificate it is commonly known
> and not to be trusted, also not sure how to handle subject name
> - assuming everyone to supply a valid certificate is quite complicated (CA
> must be on VR etc), and makes it considerably harder to get a working setup
> - using self signed causes issues with validation
> Don't get me wrong, I love the idea, but it's not just to flip a switch and
> have (proper) SSL in place.
> --
> Erik
> 
> 

Re: A secure way to reset VMs password

[John Kinsella]

That password reset infrastructure has bigger issues than just SSL. The server 
side works, but that’s about all I can say for it. This topic comes up every 
6-12 months. :)

I thought there was a Jira entry but I can’t find it…personally I’d love to see 
the client and server sides both rewritten from scratch.

John

> On Nov 28, 2014, at 11:33 AM, Nux!  wrote:
> 
> Jayapal,
> 
> Not necesarily, one could run stunnel or nginx as SSL proxy on some other 
> port (8443?), this way SSL and non-SSL connections will still work and give 
> you plenty of time to update your templates, if you so wish.
> 
> Am I missing any important bits here?
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Jayapal Reddy Uradi" 
>> To: "" 
>> Cc: "Alireza Eskandari" 
>> Sent: Friday, 28 November, 2014 09:34:02
>> Subject: Re: A secure way to reset VMs password
> 
>> Another point to note is all the vms in production has to update
>> with the new cloud-set-guest-password scripts because of the new password 
>> reset
>> method.
>> 
>> Thanks,
>> Jayapal
>> 
>> 
>> 
>> On 28-Nov-2014, at 2:28 PM, Erik Weber 
>> wrote:
>> 
>>> On Thu, Nov 27, 2014 at 3:54 PM, Alireza Eskandari <
>>> astro.alir...@yahoo.com.invalid> wrote:
>>> 
 HiI viewed the bash script that resets Linux password (
 http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in)It
 seems that it doesn't use a secure way for transferring password string to
 instance.Instances on a shared network can sniff password requests and
 export requested password of other instances.I suggest to use SSL (https)
 instead of plan text.Regards
 
 
>>> I like the idea, but there's a couple of obstacles to overcome, namely
>>> which SSL certificates to use.
>>> - certificates need a subject name, ie. IP or hostname for web pages, you
>>> could solve this by making the mgmt server a CA and have each VR get a
>>> signed certificate by it, but it's complicated
>>> - if the community bundle a pre generated certificate it is commonly known
>>> and not to be trusted, also not sure how to handle subject name
>>> - assuming everyone to supply a valid certificate is quite complicated (CA
>>> must be on VR etc), and makes it considerably harder to get a working setup
>>> - using self signed causes issues with validation
>>> 
>>> 
>>> Don't get me wrong, I love the idea, but it's not just to flip a switch and
>>> have (proper) SSL in place.
>>> 
>>> --
>>> Erik

Re: Shellshock

[John Kinsella]

I’m not worried about any specific use-case, but I’d rather not have vulnerable 
software running on SSVMs in general.

John

On Sep 30, 2014, at 2:47 PM, Sheng Yang 
mailto:sh...@yasker.org>> wrote:

The parameters of system() function have been verified as valid IP/netmask
format by script, so I don't think other parameters would be able to slip
in in this case.

--Sheng

On Tue, Sep 30, 2014 at 8:38 AM, Go Chiba 
mailto:go.ch...@gmail.com>> wrote:

Hi folks,

By my digging, ipcalc included system() function call but debian based our
system vm are using dash as system shell. So I think this shellshock
concern are not directly affected to system vm cgi-bin. right?

GO

from my iPhone

2014/09/30 10:13、Demetrius Tsitrelis 
mailto:demetrius.tsitre...@citrix.com>>
のメッセージ:

http://systemvm-public-ip/cgi-bin/ipcalc is a perl script.

-Original Message-
From: Sheng Yang [mailto:sh...@yasker.org]
Sent: Monday, September 29, 2014 5:21 PM
To: mailto:dev@cloudstack.apache.org>>
Subject: Re: Shellshock

http://systemvm-public-ip/cgi-bin/ipcalc is NOT a bash script, so it's
normal that it cannot be exploited.

--Sheng

On Fri, Sep 26, 2014 at 1:57 PM, Demetrius Tsitrelis <
demetrius.tsitre...@citrix.com> wrote:

Do you mean you tried setting the USER_AGENT like in
https://community.qualys.com/blogs/securitylabs/2014/09/25/qualysguard
-remote-detection-for-bash-shellshock
?


-Original Message-
From: Ian Duffy [mailto:i...@ianduffy.ie]
Sent: Friday, September 26, 2014 6:56 AM
To: CloudStack Dev
Subject: Re: Shellshock

Tried this against the latest system vms built on Jenkins.

Didn't get a successful exploited response. Tested against
http://systemvm
- public-ip/cgi-bin/ipcalc
On 25 Sep 2014 16:56, "Abhinandan Prateek" 
wrote:


After heart bleed we are Shell shocked
http://www.bbc.com/news/technology-29361794 !
It may not affect cloudstack directly as it is a vulnerability that
affects bash, and allows the attacker to take control of the system
running bash shell.

-abhi



Stratosec - Secure Finance and Heathcare Clouds
http://stratosec.co
o: 415.315.9385
@johnlkinsella

Re: Shellshock

[John Kinsella]

Yep, working on formal/better instructions.

On Sep 26, 2014, at 12:30 PM, David Nalley 
mailto:da...@gnsa.us>> wrote:

I am not sure that we are done with the vulnerabilities; and I think
the apt-get is a poor option to tell folks because they are vulnerable
again the next time a machine respawns.


On Fri, Sep 26, 2014 at 2:56 PM, John Kinsella 
mailto:j...@stratosec.co>> wrote:
I just tried some older virtual routers, and they are:

root@r-163-VM:~# env x='() { :;}; echo OOPS' bash -c /usr/bin/true
OOPS
bash: /usr/bin/true: No such file or directory

That said, you can only ssh to them from the local hypervisor. Not sure if 
there’s any exposure on the http side.

Running apt-get update && apt-get install bash patches the bash vuln.

I’ll put together a formal statement.

On Sep 26, 2014, at 6:55 AM, Ian Duffy 
mailto:i...@ianduffy.ie><mailto:i...@ianduffy.ie>> wrote:

Tried this against the latest system vms built on Jenkins.

Didn't get a successful exploited response. Tested against http://systemvm
- public-ip/cgi-bin/ipcalc
On 25 Sep 2014 16:56, "Abhinandan Prateek" 
mailto:agneya2...@gmail.com><mailto:agneya2...@gmail.com>>
 wrote:


After heart bleed we are Shell shocked
http://www.bbc.com/news/technology-29361794 !
It may not affect cloudstack directly as it is a vulnerability that
affects bash, and allows the attacker to take control of the system running
bash shell.

-abhi

Stratosec - Secure Finance and Heathcare Clouds
http://stratosec.co
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>


Stratosec - Secure Finance and Heathcare Clouds
http://stratosec.co
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>

Re: Shellshock

[John Kinsella]

I just tried some older virtual routers, and they are:

root@r-163-VM:~# env x='() { :;}; echo OOPS' bash -c /usr/bin/true
OOPS
bash: /usr/bin/true: No such file or directory

That said, you can only ssh to them from the local hypervisor. Not sure if 
there’s any exposure on the http side.

Running apt-get update && apt-get install bash patches the bash vuln.

I’ll put together a formal statement.

On Sep 26, 2014, at 6:55 AM, Ian Duffy 
mailto:i...@ianduffy.ie>> wrote:

Tried this against the latest system vms built on Jenkins.

Didn't get a successful exploited response. Tested against http://systemvm
- public-ip/cgi-bin/ipcalc
On 25 Sep 2014 16:56, "Abhinandan Prateek" 
mailto:agneya2...@gmail.com>> wrote:


After heart bleed we are Shell shocked
http://www.bbc.com/news/technology-29361794 !
It may not affect cloudstack directly as it is a vulnerability that
affects bash, and allows the attacker to take control of the system running
bash shell.

-abhi

Stratosec - Secure Finance and Heathcare Clouds
http://stratosec.co
o: 415.315.9385
@johnlkinsella

Re: [DISCUSS] CloudStack Future

[John Kinsella]

Ah, from that POV. Gotchya. I think also making it easier to develop the UI 
would help. Feels like a big black box to me, and probably to others…


On Sep 16, 2014, at 10:37 PM, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>> wrote:

So, most of the developers of CloudStack don’t use it as a user. If we dogfood, 
we make try to make it more user friendly and improve its UX over time.

Re: [DISCUSS] CloudStack Future

[John Kinsella]

I love seeing thoughts/actions around organizing. 

but… (Rohit, you keep doing good stuff and I keep popping up to be negative, 
sorry :) )

Can we do this within the ASF infrastructure? Trello is cool (I’ve used it 
internally in the past) but can’t we do this on a Confluence page? This allows 
folks to use existing ASF credentials to be part of the party.  If there’s 
major reasons (usability or otherwise) that we can’t, let us know them. I know 
at least Rohit likes the cool new toys (not meant in a bad way) and that ASF 
usually won’t have the cool new toys (also not meant in a bad way) but I think 
we’ll benefit from building our sand castles within the existing sandbox…

That said…

ACS demo appliance - let’s chat on this one, I’ve got the basics in place 
https://www.youtube.com/watch?v=Ql8eAO9rvQE I’ve been slowly gearing to push 
that to https://github.com/jlk/LiveCloud

“Aim for stable master” gives me a really big :( but I get it.

Under Development column, what’s “ET” ?

VM importer shouldn’t be in development - this needs to be in production 
releases.

Would like to see an expansion on “developer dogfooding” - e.g. develop within 
ACS VMs, or??

Keep running with this - I’d just rather see it happening on existing 
"old-school" technology that Rohit doesn’t like ;)

John

Also, I believe we have a Jira Aglie license, so if we really want to go down 
this path we can create agile/kanban stories/epics and do that whole thing.

On Sep 16, 2014, at 3:55 PM, Outback Dingo  wrote:

> Some of us would love to contribute, yet don't feel the requirement to
> sign-up for "sites" to simply post their feelings.
> That being said... heres mine in public.. remove the "dependency"
> on NFS as primary/secondary allow
> for more configurable storage options. Its one of the reasons why we
> dropped cloudstack. That and certain networking
> configuration requirements didn't fit our network topology.
> 
> On Wed, Sep 17, 2014 at 2:51 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
> 
>> Hi everyone,
>> 
>> First: Thanks to Rohit and Daan for working on this.
>> 
>> Next: Definitely feel free to e-mail ideas privately; however, I'd like to
>> especially encourage people to make their ideas known publicly, if you feel
>> comfortable doing this. Doing it publicly might make it easier for us as a
>> community to brainstorm the ideas and play around with taking them in
>> different directions.
>> 
>> Thanks!
>> Mike
>> 
>> On Tue, Sep 16, 2014 at 3:08 AM, Rohit Yadav 
>> wrote:
>> 
>>> Hi everyone,
>>> 
>>> Some of us are in Amsterdam and discussing various things we want to do
>>> for the project. I’ve aggregated some of them on a Trello board here:
>>> https://trello.com/b/nj8dDBWl/apache-cloudstack-future
>>> 
>>> Please share your ideas, publicly or private to me; I’ll add them on the
>>> board. Our main focus right now is testing, release quality and aligning
>>> efforts.
>>> 
>>> We’re now able to run simulator tests on TravisCI for 4.4 and master
>>> branches:
>>> https://travis-ci.org/apache/cloudstack/builds
>>> 
>>> Some of us are also experimenting with Github pull requests and we
>> already
>>> see that it’s encouraging to get TravisCI verify them.
>>> 
>>> Regards,
>>> Rohit Yadav
>>> Software Architect, ShapeBlue
>>> M. +41 779015219 | rohit.ya...@shapeblue.com
>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>> 
>>> Find out more about ShapeBlue and our range of CloudStack related
>> services
>>> 
>>> IaaS Cloud Design & Build<
>>> http://shapeblue.com/iaas-cloud-design-and-build//>
>>> CSForge – rapid IaaS deployment framework
>>> CloudStack Consulting
>>> CloudStack Infrastructure Support<
>>> http://shapeblue.com/cloudstack-infrastructure-support/>
>>> CloudStack Bootcamp Training Courses<
>>> http://shapeblue.com/cloudstack-training/>
>>> 
>>> This email and any attachments to it may be confidential and are intended
>>> solely for the use of the individual to whom it is addressed. Any views
>> or
>>> opinions expressed are solely those of the author and do not necessarily
>>> represent those of Shape Blue Ltd or related companies. If you are not
>> the
>>> intended recipient of this email, you must neither take any action based
>>> upon its contents, nor copy or show it to anyone. Please contact the
>> sender
>>> if you believe you have received this email in error. Shape Blue Ltd is a
>>> company incorporated in England & Wales. ShapeBlue Services India LLP is
>> a
>>> company incorporated in India and is operated under license from Shape
>> Blue
>>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
>> Brasil
>>> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd
>> is
>>> a company registered by The Republic of South Africa and is traded under
>>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>>> 
>> 
>> 
>> 
>> --
>> *Mike Tutkowski*
>> *S

Re: IPv6 ~ Basic Network

[John Kinsella]

The neighbor table attack scenario reminds me of VLAN flattening attack 
scenarios of days past - in theory you could blast a switch hard enough that 
the switch’s CPU lowers VLAN tagging priority and the network “flattens” out, 
turning switch into hub. In reality, the vendors quickly realized the situation 
as less-than-optimal and coded around it. 

This thread got me thinking of something else that might be interesting to 
think about: what about having virtual routers proxy DHCP requests[1] for v4 or 
v6? 

John
1: 
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_relaying

On Sep 5, 2014, at 7:52 AM, Wido den Hollander  wrote:

> 
> 
> On 05-09-14 12:42, Nux! wrote:
>> Hi,
>> 
>> I've been thinking about this and apparently there is a big security problem 
>> with this idea, at least my colleagues from the network dept tell me so.
>> If you want to use the router autoconfig thingy you must - as per current 
>> standards - use a /64 on the router interface and this way you expose 
>> yourself to a neighbour table attack - the neighbour table in avg cisco 
>> routers can hold tens of thousands of entries more or less, but it's still 
>> far from the trillions of addresses in a /64. This may seem far fetched but 
>> since 512k day, my colleagues don't want to take any more chances. :-)
> 
> That only works if you actually spawn thousands of instances in that subnet.
> 
> One of the things people told me that you could overflow the neighbour table 
> by sending packets to bogus IPv6 addresses.
> 
> I tried that some weeks ago on a Brocade and Extreme Networks router, but 
> they both have a system of "valid neighbours" and "pending neighbours".
> 
> Only when a neighbour actually responded it goes into the "valid" table and 
> otherwise it is kicked out of the "pending" pretty quickly.
> 
> I could not overflow any table or make them drop traffic to legitimate hosts.
> 
>> They recommend to use DHCPv6 instead with far smaller subnets, which of 
>> course complicates things quite a bit on the cloudstack side...
>> 
> 
> Well, we would still need DHCPv6 to hand out additional options like DNS, but 
> yes. Since with the subnet + MAC you can calculate which IPv6 address the 
> Instance will use based on SLAAC.
> 
> We can program that address into the security groups and that's the IPv6 
> address the guest can use.
> 
> Additional IPs is just a matter of generating a address, storing it and 
> adding it to the SG.
> 
> So Router Advertisements are a very easy option to use.
> 
>> Any thoughts?
>> 
>> Lucian
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
>> - Original Message -
>>> From: "John Kinsella" 
>>> To: dev@cloudstack.apache.org
>>> Sent: Wednesday, 20 August, 2014 11:59:27 PM
>>> Subject: Re: IPv6 ~ Basic Network
>>> 
>>> Please do - we started tinkering with ipv6 ages ago, never got it to
>>> production, tho.
>>> 
>>> On Aug 20, 2014, at 3:48 PM, Nux!  wrote:
>>> 
>>>> Thanks Wido for the idea, then. :-)
>>>> I'll gladly share it with you guys should I come up with something that
>>>> works.
>>>> 
>>>> Lucian
>>>> 
>>>> --
>>>> Sent from the Delta quadrant using Borg technology!
>>>> 
>>>> Nux!
>>>> www.nux.ro
>>>> 
>>>> 
>>>> - Original Message -
>>>>> From: "Wido den Hollander" 
>>>>> To: dev@cloudstack.apache.org
>>>>> Sent: Wednesday, 20 August, 2014 9:36:48 PM
>>>>> Subject: Re: IPv6 ~ Basic Network
>>>>> 
>>>>> 
>>>>> 
>>>>> On 08/20/2014 10:07 PM, Nux! wrote:
>>>>>> Wido,
>>>>>> 
>>>>>> Can you share your code for this?
>>>>>> 
>>>>> 
>>>>> Oh, I don't have any code. The setups I created have plain IPv6 without
>>>>> any security grouping.
>>>>> 
>>>>> My previous e-mail was just to illustrate what would be required.
>>>>> 
>>>>> Wido
>>>>> 
>>>>>> Cheers
>>>>>> 
>>>>>> --
>>>>>> Sent from the Delta quadrant using Borg technology!
>>>>>> 
>>>>>> Nux!
>>>>>> www.nux.ro
>>>>>> 
>>>>> 
>>> 
>>> 
>>> 

Re: [DISCUSS] Changing the way password reset works, or allowing the cloud-init way

[John Kinsella]

Is that open source? I’ve been eyeing doing something with that virtio serial 
path for a long time…seems like it’d be a great improvement.

On Aug 26, 2014, at 7:47 PM, Marcus 
mailto:shadow...@gmail.com>> wrote:

We had set up an agent in the VM that listens on the virtio serial port,
similar to how the virtual router gets its configurations now in KVM. Host
to guest communication is an option, and is fairly standardized (qemu guest
agent, VMware tools, xen tools). It takes a little more work to write a
daemon, but you could do a lot more with it.

 I'm not entirely convinced the current design is broken enough to warrant
a redesign (or at least I wouldn't want to see compatibility go away).
On Aug 26, 2014 6:51 PM, "Chiradeep Vittal" 
mailto:chiradeep.vit...@citrix.com>>
wrote:

The current design is “OK”, not great. Looking for suggestions to make it
more secure. E.g.,:

 *   HTTPS
 *   Client authentication

Another idea might be to attach a volume to the VM with the password, but
hot plug detection varies widely from OS/Hypervisor combinations.
HTTP(s) is the lowest common denominator, but it has some trade-offs.

From: John Kinsella 
mailto:j...@stratosec.co><mailto:j...@stratosec.co>>
Reply-To: 
"dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>"
 <
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>>
Date: Tuesday, August 26, 2014 at 4:04 PM
To: 
"dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>"
 <
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Changing the way password reset works, or allowing
the cloud-init way


On Aug 26, 2014, at 1:34 PM, Erik Weber 
mailto:terbol...@gmail.com>mailto:terbol...@gmail.com>>> wrote:
If I understand correctly, we currently deploy a web server on port 8080 on

Slight correction: A processes on the VR listens on port 8080, and hands
any connections to a UNIX script. Calling it a "web server" is way too kind.

Also, you’re just looking at the unix use-case. The Windows agent is close
sourced the last I checked.

Cloud-init doesn’t feel like the best solution, as the one good thing the
current setup does is remove the password from the VR after it’s fetched.

Thought there was a bug filed on this, but I don’t see it?




Stratosec - Secure Finance and Heathcare Clouds
http://stratosec.co
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>

Re: [DISCUSS] Changing the way password reset works, or allowing the cloud-init way

[John Kinsella]

SSL - maybe we could use the same SSL cert used for the CP and secure download? 
Feels a little sketchy at first thought but might be an improvement...

John

On Aug 26, 2014, at 5:51 PM, Chiradeep Vittal  
wrote:

> The current design is “OK”, not great. Looking for suggestions to make it 
> more secure. E.g.,:
> 
>  *   HTTPS
>  *   Client authentication
> 
> Another idea might be to attach a volume to the VM with the password, but hot 
> plug detection varies widely from OS/Hypervisor combinations.
> HTTP(s) is the lowest common denominator, but it has some trade-offs.
> 
> From: John Kinsella mailto:j...@stratosec.co>>
> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
> mailto:dev@cloudstack.apache.org>>
> Date: Tuesday, August 26, 2014 at 4:04 PM
> To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
> mailto:dev@cloudstack.apache.org>>
> Subject: Re: [DISCUSS] Changing the way password reset works, or allowing the 
> cloud-init way
> 
> 
> On Aug 26, 2014, at 1:34 PM, Erik Weber 
> mailto:terbol...@gmail.com>> wrote:
> If I understand correctly, we currently deploy a web server on port 8080 on
> 
> Slight correction: A processes on the VR listens on port 8080, and hands any 
> connections to a UNIX script. Calling it a "web server" is way too kind.
> 
> Also, you’re just looking at the unix use-case. The Windows agent is close 
> sourced the last I checked.
> 
> Cloud-init doesn’t feel like the best solution, as the one good thing the 
> current setup does is remove the password from the VR after it’s fetched.
> 
> Thought there was a bug filed on this, but I don’t see it?
> 
> 

Re: Filesystem XFS

[John Kinsella]

Besides network filesystems, CloudStack should be filesystem-agnostic. It’s an 
application that sits on top of whatever FS you pick.

On Aug 27, 2014, at 5:11 AM, mo  wrote:

> Hello Dev Folks,
> 
> Is there any particular filesystem that Cloudstack does not appreciate. I was 
> considering doing a new install utilizing XFS. 
> 
> Anyone have this, or run into issues utilizing this FS type?
> 
> - Mo
> 

Re: [DISCUSS] Changing the way password reset works, or allowing the cloud-init way

[John Kinsella]

On Aug 26, 2014, at 1:34 PM, Erik Weber  wrote:
> If I understand correctly, we currently deploy a web server on port 8080 on

Slight correction: A processes on the VR listens on port 8080, and hands any 
connections to a UNIX script. Calling it a "web server" is way too kind.

Also, you’re just looking at the unix use-case. The Windows agent is close 
sourced the last I checked.

Cloud-init doesn’t feel like the best solution, as the one good thing the 
current setup does is remove the password from the VR after it’s fetched. 

Thought there was a bug filed on this, but I don’t see it?

Re: [VOTE] Adapting git workflow for release branches

[John Kinsella]

Let’s keep this civil, folks.

Re: IPv6 ~ Basic Network

[John Kinsella]

Please do - we started tinkering with ipv6 ages ago, never got it to 
production, tho.

On Aug 20, 2014, at 3:48 PM, Nux!  wrote:

> Thanks Wido for the idea, then. :-)
> I'll gladly share it with you guys should I come up with something that works.
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> 
> - Original Message -
>> From: "Wido den Hollander" 
>> To: dev@cloudstack.apache.org
>> Sent: Wednesday, 20 August, 2014 9:36:48 PM
>> Subject: Re: IPv6 ~ Basic Network
>> 
>> 
>> 
>> On 08/20/2014 10:07 PM, Nux! wrote:
>>> Wido,
>>> 
>>> Can you share your code for this?
>>> 
>> 
>> Oh, I don't have any code. The setups I created have plain IPv6 without
>> any security grouping.
>> 
>> My previous e-mail was just to illustrate what would be required.
>> 
>> Wido
>> 
>>> Cheers
>>> 
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> 
>>> Nux!
>>> www.nux.ro
>>> 
>> 

Re: KVM + LXC on the same host

[John Kinsella]

Hey Ilya -

So, for about a month now we’ve had a system running SmartOS[1], which gives a 
combination of containers and KVM, albeit on illumos instead of linux. In 
general I’m not impressed by SmartOS’s story, but we had one customer asking 
for it (and I sorta expect more, we’re not officially supporting it yet). It’s 
a little early for me to even ponder integrating it with ACS, but might but 
worth a glance if you’re looking for that KVM/container mix. 

Downsides:
 * Compared to a Linux hypervisor, much less feature support (missing Ceph is 
personally bugging me)
 * It’s…Solaris (the OS that won’t go away, c0t0d0s0 gives me flashbacks from 
10 years ago). For us our infrastructure/automation is fairly tuned for linux, 
so really embracing this will require…effort.

John
1: http://smartos.org/

On Jun 4, 2014, at 5:58 PM, ilya musayev  wrote:

> We are considering running KVM and LXC on the same host and hopefully control 
> both through cloudstack.
> 
> I know there are agents involved for each component, i dont know if we can 
> have a hybrid of LXC+KVM.
> 
> The use case is simple, we would like the end user to pick LXC/Docker for 
> performance, or KVM instance if he really needed all bells and whistles of 
> dedicated kernel in fully virtualized environment.
> 
> Is anyone aware why we should not mix 2 workloads on the same host? Is it 
> possible at this point in time to mix LXC, KVM and CloudStack, i assume the 
> answer is no, but perhaps there is a hack i can try.
> 
> Thanks
> ilya

Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality...

[John Kinsella]

+1 seems like a good idea.

On Jun 6, 2014, at 4:26 PM, Sheng Yang 
mailto:sh...@yasker.org>> wrote:

Hi all,

Seems it's a good timing to bring back the discussion about the gerrit.

We want to do CI, and improve our code quality. One obvious way of doing
and reduce the workload of devs is introduce a tool to enforce the process.

I've checked out quite a few projects using gerrit, which would force you
to ask for review, and validation before the code can be committed to the
repo. Looks it's really a easier way for devs according what I've heard.

Even our competitor laid out a very detail workflow based on the use of
gerrit( https://wiki.openstack.org/wiki/Gerrit_Workflow ). I guess it can
make a good reference.

Well, gerrit has been brought up a few times before. And now the new
process we want to enforce just fits what gerrit(or other automation
review/test/commit software) is for.

Maybe it's the time for us to review the possibility of using a tool to
enforce our commits and improve our code quality(as well as transfer
knowledge) again?

--Sheng


On Tue, May 27, 2014 at 8:28 PM, David Nalley 
mailto:da...@gnsa.us>> wrote:

On Tue, May 27, 2014 at 12:52 PM, Alex Huang 
mailto:alex.hu...@citrix.com>>
wrote:
Like Chip, I am very concerned with this being dependent on a single
company, even if its the company that employs me. It isn't sustainable,
it
excludes others from contributing, and makes the project less
independent
because it depends on a single company's infrastructure.

Agreed there.


I'm also unclear on the answer to the question in the FAQ. The first
time I
read it, I got the impression that you were happy to bring it up on
hardware
at the ASF if the ASF wanted to own it. The second time I read it I
wondered
if you meant that Citrix was going to attempt to donate hardware.

Sorry if I did not make that clear.  I meant the scripts/code that we
wrote are checked in publicly and we're willing to help set it up if ASF
provided the hardware.  I have not approach Citrix on donating the actual
hardware.  Although I can approach them if it speeds up the adoption
process.

Finally - what do you think you need from ASF infra to make this happen?


It's currently about 10 servers with two networks.  One network is
static with IPMI to PXE boot the machines.  The other network is the actual
data network that CloudStack uses.  That's actually just enough for
XenServer and KVM.  In order to accommodate for HyperV, Bare Metal, LXC,
(which we do not have any test cases in the automation suits currently) we
will need even more machines.  We might be able to use nested
virtualization for the hypervisors to maintain server count at ten or a
little more than ten but we haven't explore that yet.

The CI process is up and running on those machines but because we didn't
have CI running on master before, automation tests that were passing for
4.3 are now broken again on 4.4. and master.  I think Sudha already
reported on the list that QA is busy trying to fix all the automation tests
to bring CI on 4.4-forward and master back to 100% pass rate.
Unfortunately, it's been delaying our effort to put this out in the public
and let the community try this themselves.

--Alex


So the board just approved a 3 month budget, but the new board will
have to take up the remainder of the FY budget shortly after coming
into office. Perhaps worth coming up with an estimate of what this
will cost/need and getting it to president@ before that new budget is
taken up.

--David


Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

[ANNOUNCE] Demetrius Tsitrelis as committer

[John Kinsella]

Folks - this one’s a little belated - we went through the invite process around 
the
time of the mail issues, and somehow we didn’t send the announcement to dev@.
I noticed while doing some housekeeping this week, and wanted to send out the
announcement anyways just to give Demetrius the recognition. :)

The Project Management Committee (PMC) for Apache CloudStack has
asked Demetrius Tsitrelis to become a committer and we are pleased to announce
that he has accepted.

Being a committer allows many contributors to contribute more autonomously. For
developers, it makes it easier to submit changes and eliminates the need to
have contributions reviewed via the patch submission process. Whether
contributions are development-related or otherwise, it is a recognition of a
contributor's participation in the project and commitment to the project and
the Apache Way.

Please join me in congratulating Demetrius!

-John, on behalf of the CloudStack PMC

[ANNOUNCE] Amogh Vasekar as committer

[John Kinsella]

The Project Management Committee (PMC) for Apache CloudStack has
asked Amogh Vasekar to become a committer and we are pleased to announce
that he has accepted.

Being a committer allows many contributors to contribute more autonomously. For
developers, it makes it easier to submit changes and eliminates the need to
have contributions reviewed via the patch submission process. Whether
contributions are development-related or otherwise, it is a recognition of a
contributor's participation in the project and commitment to the project and
the Apache Way.

Please join me in congratulating Amogh!

-John, on behalf of the CloudStack PMC

REMINDER realhostip going away

[John Kinsella]

Reminder, folks - please migrate off realhostip.com or you’re going to get a 
nasty surprise this summer. More info at link below.

https://blogs.apache.org/cloudstack/entry/realhostip_service_is_being_retired

Re: OpenSSL vunerability (bleedheart)

[John Kinsella]

root@v-14-VM:~# lsof|grep -i ssl
monit 11461   root  mem   REG  254,7   358880  15115 
/usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0
root@v-14-VM:~# ps -ef|grep monit
root 11461 1  0 Apr09 ?00:00:02 /usr/bin/monit -c 
/etc/monit/monitrc

On Apr 9, 2014, at 9:10 PM, Kelven Yang 
mailto:kelven.y...@citrix.com>> wrote:

What is the process name of that daemon in CPVM? I remember that we only
have SSH and HTTPS port open in console proxy, and the later one is
running Java based SSL engine.

Kelven

On 4/9/14, 1:38 PM, "John Kinsella" 
mailto:j...@stratosec.co>> wrote:

CPVM runs a monit daemon which is at least linked to libssl. I haven¹t
taken more than peek at that yet - I think SSL is configured off by
default butŠyeah sorry will have to look at that closer.

Regarding the trusted IPs - I only attempted to test one SSVM from
http://filippo.io/Heartbleed/ and it was a) publicly accessible and b)
vulnerable, so trust didn¹t really enter into the equation.

I already adjusted the blog post re: VR and earlier versions of ACS.

John

On Apr 9, 2014, at 12:15 PM, Animesh Chaturvedi
mailto:animesh.chaturv...@citrix.com><mailto:animesh.chaturv...@citrix.com>>
wrote:

Courtesy Chiradeep


- CPVM uses JSSE so that should not be affected
- VR is not affected since it does not offer any HTTPS/TLS service. The
RA VPN and S2S VPN use the OpenSSL lib only for crypto and not for any
transport
- The only vulnerable service is the volume upload service and template
copy. The latter is between 2 trusted IPs
- Also this should only affect SSVM template from 4.2 onwards as only
wheezy is affected

Thanks
Animesh
-----Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Wednesday, April 09, 2014 11:07 AM
To: 
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>
Subject: Re: OpenSSL vunerability (bleedheart)

I want to address a few things here directly (I think these are covered
in the
blog post, if not ping me)

* Current SSVM from 4.3 is not good enough.
* Yes, each SystemVM runs software that needs OpenSSL. For the curious,
see "lsof|grep -i ssl"
* I'm not sure if the current SystemVM template on Jenkins is secure,
we're
testing that currently and will update once confirmed.
* Assume if you see us releasing a blog post about a security issue,
there's a
security issue (QED HTH HAND)
* Realhostip uses SSL, but not on the SystemVMs. If you're using
realhostIP,
it doesn't matter what version of OSSL you use, you're still insecure.
Horse:
beaten.
* Chiradeep's correct, 4.1 and older are not vulnerable. Post updated
again.

I think that covers the questions...running around doing a few things but
this
is very high on our priority list.

(snarky comments are meant to be funny not insulting/condescending)

On Apr 9, 2014, at 10:19 AM, John Kinsella
mailto:j...@stratosec.co><mailto:j...@stratosec.co><mailto:j...@stratosec.co>>
wrote:

To my knowledge, no code change is necessary just a rebuild.  - j

Please excuse typos - sent from mobile device.

- Reply message -
From: "Rayees Namathponnan"
mailto:rayees.namathpon...@citrix.com><mailto:rayees.namathpon...@citrix.com>http://citrix.co>
m>>
To:
"dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org><mailto:dev@cl
oudstack.apache.org<http://oudstack.apache.org>>"
mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org><mailto:dev@cl
oudstack.apache.org<http://oudstack.apache.org>>>
Subject: OpenSSL vunerability (bleedheart)
Date: Wed, Apr 9, 2014 10:13 AM

Even if we get latest systemvm template from
http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-systemvm/ . ,
it
has openssl 1.0.1e-2+deb7u4 ?

Is there any code change required to create system template with openssl
1.0.1e-2+deb7u6  ?

Regards,
Rayees

-Original Message-
From: Harikrishna Patnala [mailto:harikrishna.patn...@citrix.com]
Sent: Wednesday, April 09, 2014 5:15 AM
To:
mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org><mailto:dev@cl
oudstack.apache.org<http://oudstack.apache.org>>>
Subject: Re: OpenSSL vunerability (bleedheart)

Latest System VMs have openssl 1.0.1e-2+deb7u4. We need to update
openssl to get 1.0.1e-2+deb7u6.

It will be great if some one can update openssl to 1.0.1e-2+deb7u6 and
test
OpenSSL HeartBleed Vulnerability. Right now I could not do it from our
network.

-Harikrishna

On 09-Apr-2014, at 5:00 pm, Nux!
mailto:n...@li.nux.ro><mailto:n...@li.nux.ro><mailto:n...@li.nux.ro>>
wrote:

On 09.04.2014 12:04, Abhinandan Prateek wrote:
Latest jenkins build template have openSSL version 1.0.1e, the version
that is
compromised.

Guys, do not panic.
It is my understanding that in Debia

Re: OpenSSL vunerability (bleedheart)

[John Kinsella]

CPVM runs a monit daemon which is at least linked to libssl. I haven’t taken 
more than peek at that yet - I think SSL is configured off by default but…yeah 
sorry will have to look at that closer.

Regarding the trusted IPs - I only attempted to test one SSVM from 
http://filippo.io/Heartbleed/ and it was a) publicly accessible and b) 
vulnerable, so trust didn’t really enter into the equation.

I already adjusted the blog post re: VR and earlier versions of ACS.

John

On Apr 9, 2014, at 12:15 PM, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>> wrote:

Courtesy Chiradeep


- CPVM uses JSSE so that should not be affected
- VR is not affected since it does not offer any HTTPS/TLS service. The RA VPN 
and S2S VPN use the OpenSSL lib only for crypto and not for any transport
- The only vulnerable service is the volume upload service and template copy. 
The latter is between 2 trusted IPs
- Also this should only affect SSVM template from 4.2 onwards as only wheezy is 
affected

Thanks
Animesh
-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Wednesday, April 09, 2014 11:07 AM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Subject: Re: OpenSSL vunerability (bleedheart)

I want to address a few things here directly (I think these are covered in the
blog post, if not ping me)

* Current SSVM from 4.3 is not good enough.
* Yes, each SystemVM runs software that needs OpenSSL. For the curious,
see "lsof|grep -i ssl"
* I'm not sure if the current SystemVM template on Jenkins is secure, we're
testing that currently and will update once confirmed.
* Assume if you see us releasing a blog post about a security issue, there's a
security issue (QED HTH HAND)
* Realhostip uses SSL, but not on the SystemVMs. If you're using realhostIP,
it doesn't matter what version of OSSL you use, you're still insecure. Horse:
beaten.
* Chiradeep's correct, 4.1 and older are not vulnerable. Post updated again.

I think that covers the questions...running around doing a few things but this
is very high on our priority list.

(snarky comments are meant to be funny not insulting/condescending)

On Apr 9, 2014, at 10:19 AM, John Kinsella
mailto:j...@stratosec.co><mailto:j...@stratosec.co>> wrote:

To my knowledge, no code change is necessary just a rebuild.  - j

Please excuse typos - sent from mobile device.

- Reply message -
From: "Rayees Namathponnan"
mailto:rayees.namathpon...@citrix.com><mailto:rayees.namathpon...@citrix.co
m>>
To: 
"dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>"
mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>>
Subject: OpenSSL vunerability (bleedheart)
Date: Wed, Apr 9, 2014 10:13 AM

Even if we get latest systemvm template from
http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-systemvm/ . , it
has openssl 1.0.1e-2+deb7u4 ?

Is there any code change required to create system template with openssl
1.0.1e-2+deb7u6  ?

Regards,
Rayees

-Original Message-
From: Harikrishna Patnala [mailto:harikrishna.patn...@citrix.com]
Sent: Wednesday, April 09, 2014 5:15 AM
To: 
mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>>
Subject: Re: OpenSSL vunerability (bleedheart)

Latest System VMs have openssl 1.0.1e-2+deb7u4. We need to update
openssl to get 1.0.1e-2+deb7u6.

It will be great if some one can update openssl to 1.0.1e-2+deb7u6 and test
OpenSSL HeartBleed Vulnerability. Right now I could not do it from our
network.

-Harikrishna

On 09-Apr-2014, at 5:00 pm, Nux! 
mailto:n...@li.nux.ro><mailto:n...@li.nux.ro>>
wrote:

On 09.04.2014 12:04, Abhinandan Prateek wrote:
Latest jenkins build template have openSSL version 1.0.1e, the version that is
compromised.

Guys, do not panic.
It is my understanding that in Debian, just like in RHEL, major versions will
not change, i.e. Debian GNU/Linux 7.0 will EOL with openssl 1.0.1e, but they
will backport stuff.

After I did an "apt-get update && apt-get install openssl" I got package
version 1.0.1e-2+deb7u6 (dpkg -l|grep openssl) and this package is ok
according to the changelog:

"aptitude changelog openssl" says:

openssl (1.0.1e-2+deb7u6) wheezy-security; urgency=high

* Non-maintainer upload by the Security Team.
* Enable checking for services that may need to be restarted
* Update list of services to possibly restart

-- Salvatore Bonaccorso 
mailto:car...@debian.org><mailto:car...@debian.org>>
Tue, 08 Apr 2014 10:44:53
+0200

openssl (1.0.1e-2+deb7u5) wheezy-security; urgency=high

* Non-maintainer upload by the Security Team.
* Add CVE-2014-0160.patch patch.
 CVE-2014-0160: Fix TLS/DTLS hearbeat information disclosure.
 A missing bounds check in the handling of the TLS heartbeat extension
 can be used to reveal up to 64k of memor

Re: OpenSSL vunerability (bleedheart)

[John Kinsella]

I want to address a few things here directly (I think these are covered in the 
blog post, if not ping me)

* Current SSVM from 4.3 is not good enough.
* Yes, each SystemVM runs software that needs OpenSSL. For the curious, see 
"lsof|grep -i ssl”
* I’m not sure if the current SystemVM template on Jenkins is secure, we’re 
testing that currently and will update once confirmed.
* Assume if you see us releasing a blog post about a security issue, there’s a 
security issue (QED HTH HAND)
* Realhostip uses SSL, but not on the SystemVMs. If you’re using realhostIP, it 
doesn’t matter what version of OSSL you use, you’re still insecure. Horse: 
beaten.
* Chiradeep’s correct, 4.1 and older are not vulnerable. Post updated again.

I think that covers the questions…running around doing a few things but this is 
very high on our priority list.

(snarky comments are meant to be funny not insulting/condescending)

On Apr 9, 2014, at 10:19 AM, John Kinsella 
mailto:j...@stratosec.co>> wrote:

To my knowledge, no code change is necessary just a rebuild.  - j

Please excuse typos - sent from mobile device.

- Reply message -
From: "Rayees Namathponnan" 
mailto:rayees.namathpon...@citrix.com>>
To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
mailto:dev@cloudstack.apache.org>>
Subject: OpenSSL vunerability (bleedheart)
Date: Wed, Apr 9, 2014 10:13 AM

Even if we get latest systemvm template from 
http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-systemvm/ . , it has 
openssl 1.0.1e-2+deb7u4 ?

Is there any code change required to create system template with openssl  
1.0.1e-2+deb7u6  ?

Regards,
Rayees

-Original Message-
From: Harikrishna Patnala [mailto:harikrishna.patn...@citrix.com]
Sent: Wednesday, April 09, 2014 5:15 AM
To: mailto:dev@cloudstack.apache.org>>
Subject: Re: OpenSSL vunerability (bleedheart)

Latest System VMs have openssl 1.0.1e-2+deb7u4. We need to update openssl to 
get 1.0.1e-2+deb7u6.

It will be great if some one can update openssl to 1.0.1e-2+deb7u6 and test 
OpenSSL HeartBleed Vulnerability. Right now I could not do it from our network.

-Harikrishna

On 09-Apr-2014, at 5:00 pm, Nux! mailto:n...@li.nux.ro>> wrote:

On 09.04.2014 12:04, Abhinandan Prateek wrote:
Latest jenkins build template have openSSL version 1.0.1e, the
version that is compromised.

Guys, do not panic.
It is my understanding that in Debian, just like in RHEL, major versions will 
not change, i.e. Debian GNU/Linux 7.0 will EOL with openssl 1.0.1e, but they 
will backport stuff.

After I did an "apt-get update && apt-get install openssl" I got package 
version 1.0.1e-2+deb7u6 (dpkg -l|grep openssl) and this package is ok according 
to the changelog:

"aptitude changelog openssl" says:

openssl (1.0.1e-2+deb7u6) wheezy-security; urgency=high

* Non-maintainer upload by the Security Team.
* Enable checking for services that may need to be restarted
* Update list of services to possibly restart

-- Salvatore Bonaccorso mailto:car...@debian.org>>  Tue, 08 
Apr 2014 10:44:53
+0200

openssl (1.0.1e-2+deb7u5) wheezy-security; urgency=high

* Non-maintainer upload by the Security Team.
* Add CVE-2014-0160.patch patch.
  CVE-2014-0160: Fix TLS/DTLS hearbeat information disclosure.
  A missing bounds check in the handling of the TLS heartbeat extension
  can be used to reveal up to 64k of memory to a connected client or
  server.

-- Salvatore Bonaccorso mailto:car...@debian.org>>  Mon, 07 
Apr 2014 22:26:55
+0200

In conclusion, if System VMs have openssl 1.0.1e-2+deb7u5 or higher, then they 
are OK. Can anyone confirm they have 1.0.1e-2+deb7u5+ ?

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro<http://www.nux.ro>


Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>

Re: OpenSSL vunerability (bleedheart)

[John Kinsella]

Folks - unfortunately there’s an error in my blog post last night. On Debian, 
you need to update both openssl and libssl, updating openssl by itself is not 
good enough. I knew this, had it in a draft but somehow that didn’t make it 
into the post. I’ll blame lack of sleep.

Blog post has been updated, and I’ve also added instructions for VMWare shops, 
thanks to Geoff Higginbottom.

I can guarantee that current ACS is vulnerable, and I can attest that with our 
config (KVM) the notes in the blog post [1] will mitigate the vulnerability.

1: https://blogs.apache.org/cloudstack/entry/how_to_mitigate_openssl_heartbleed

On Apr 9, 2014, at 5:30 AM, Nux! mailto:n...@li.nux.ro>> wrote:

On 09.04.2014 12:04, Abhinandan Prateek wrote:
Latest jenkins build template have openSSL version 1.0.1e, the version
that is compromised.

Guys, do not panic.
It is my understanding that in Debian, just like in RHEL, major versions will 
not change, i.e. Debian GNU/Linux 7.0 will EOL with openssl 1.0.1e, but they 
will backport stuff.

After I did an "apt-get update && apt-get install openssl" I got package 
version 1.0.1e-2+deb7u6 (dpkg -l|grep openssl) and this package is ok according 
to the changelog:

"aptitude changelog openssl" says:

openssl (1.0.1e-2+deb7u6) wheezy-security; urgency=high

 * Non-maintainer upload by the Security Team.
 * Enable checking for services that may need to be restarted
 * Update list of services to possibly restart

-- Salvatore Bonaccorso mailto:car...@debian.org>>  Tue, 08 
Apr 2014 10:44:53 +0200

openssl (1.0.1e-2+deb7u5) wheezy-security; urgency=high

 * Non-maintainer upload by the Security Team.
 * Add CVE-2014-0160.patch patch.
   CVE-2014-0160: Fix TLS/DTLS hearbeat information disclosure.
   A missing bounds check in the handling of the TLS heartbeat extension
   can be used to reveal up to 64k of memory to a connected client or
   server.

-- Salvatore Bonaccorso mailto:car...@debian.org>>  Mon, 07 
Apr 2014 22:26:55 +0200

In conclusion, if System VMs have openssl 1.0.1e-2+deb7u5 or higher, then they 
are OK. Can anyone confirm they have 1.0.1e-2+deb7u5+ ?

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: OpenSSL vunerability (bleedheart)

[John Kinsella]

To my knowledge, no code change is necessary just a rebuild.  - j

Please excuse typos - sent from mobile device.

- Reply message -
From: "Rayees Namathponnan" 
To: "dev@cloudstack.apache.org" 
Subject: OpenSSL vunerability (bleedheart)
Date: Wed, Apr 9, 2014 10:13 AM

Even if we get latest systemvm template from 
http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-systemvm/ . , it has 
openssl 1.0.1e-2+deb7u4 ?

Is there any code change required to create system template with openssl  
1.0.1e-2+deb7u6  ?

Regards,
Rayees

-Original Message-
From: Harikrishna Patnala [mailto:harikrishna.patn...@citrix.com]
Sent: Wednesday, April 09, 2014 5:15 AM
To: 
Subject: Re: OpenSSL vunerability (bleedheart)

Latest System VMs have openssl 1.0.1e-2+deb7u4. We need to update openssl to 
get 1.0.1e-2+deb7u6.

It will be great if some one can update openssl to 1.0.1e-2+deb7u6 and test 
OpenSSL HeartBleed Vulnerability. Right now I could not do it from our network.

-Harikrishna

On 09-Apr-2014, at 5:00 pm, Nux!  wrote:

> On 09.04.2014 12:04, Abhinandan Prateek wrote:
>> Latest jenkins build template have openSSL version 1.0.1e, the
>> version that is compromised.
>
> Guys, do not panic.
> It is my understanding that in Debian, just like in RHEL, major versions will 
> not change, i.e. Debian GNU/Linux 7.0 will EOL with openssl 1.0.1e, but they 
> will backport stuff.
>
> After I did an "apt-get update && apt-get install openssl" I got package 
> version 1.0.1e-2+deb7u6 (dpkg -l|grep openssl) and this package is ok 
> according to the changelog:
>
> "aptitude changelog openssl" says:
>
> openssl (1.0.1e-2+deb7u6) wheezy-security; urgency=high
>
>  * Non-maintainer upload by the Security Team.
>  * Enable checking for services that may need to be restarted
>  * Update list of services to possibly restart
>
> -- Salvatore Bonaccorso   Tue, 08 Apr 2014 10:44:53
> +0200
>
> openssl (1.0.1e-2+deb7u5) wheezy-security; urgency=high
>
>  * Non-maintainer upload by the Security Team.
>  * Add CVE-2014-0160.patch patch.
>CVE-2014-0160: Fix TLS/DTLS hearbeat information disclosure.
>A missing bounds check in the handling of the TLS heartbeat extension
>can be used to reveal up to 64k of memory to a connected client or
>server.
>
> -- Salvatore Bonaccorso   Mon, 07 Apr 2014 22:26:55
> +0200
>
> In conclusion, if System VMs have openssl 1.0.1e-2+deb7u5 or higher, then 
> they are OK. Can anyone confirm they have 1.0.1e-2+deb7u5+ ?
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro

Re: OpenSSL vunerability (bleedheart)

[John Kinsella]

Just put up a blog post with mitigation instructions [1]. If anybody has any 
issues with this, please let us know and we’ll help/update as appropriate.

We’re working on new SystemVM images, but that’s going to take us a few days.

John
1: https://blogs.apache.org/cloudstack/entry/how_to_mitigate_openssl_heartbleed

On Apr 8, 2014, at 6:21 PM, John Kinsella  wrote:

> Folks - we’re aware of the OpenSSL issue, and are working with vendors to 
> release mitigation instructions for ACS.
> 
> Hoping to have something out later this evening.
> 
> John
> 
> On Apr 8, 2014, at 8:12 AM, Paul Angus 
> mailto:paul.an...@shapeblue.com>> wrote:
> 
> A vulnerability has been found in OpenSSL
> 
> http://www.bit-tech.net/news/bits/2014/04/08/openssl-heartbleed/1
> 
> Affected are OpenSSL versions 1.0.1 and 1.0.2-beta, which include such 
> releases as
> Debian Wheezy, Ubuntu 12.04.4 LTS, Centos 6.5, Fedora 18, OpenBSD 5.3, 
> FreeBSD 8.4, NetBSD 5.0.2 and OpenSUSE 12.2.
> 
> It is fixed in OpenSSL 1.0.1g
> 
> From https://bugzilla.redhat.com/show_bug.cgi?id=1084875#c9
> 
> "Statement:
> This issue did not affect the versions of openssl as shipped with Red Hat 
> Enterprise Linux 5 and Red Hat Enterprise Linux 6.4 and earlier. This issue 
> does affect Red Hat Enterprise Linux 6.5, Red Hat Enterprise Virtualization 
> Hypervisor 6.5, and Red Hat Storage 2.1, which provided openssl 1.0.1e."
> 
> XenServer 6.2 SP1 uses the native CentOS OpenSSL RPM without modification 
> version (OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008) so is unaffected.
> 
> 
> 
> Regards,
> 
> Paul Angus
> Senior Consultant / Cloud Architect
> 
> S: +44 20 3603 0540 | M: +447711418784 
> | T: @CloudyAngus
> paul.an...@shapeblue.com<mailto:paul.an...@shapeblue.com> | 
> www.shapeblue.com | 
> Twitter:@shapeblue<https://twitter.com/>
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
> 
> Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure 
> Support<http://shapeblue.com/cloudstack-infrastructure-support/> offers the 
> best 24/7 SLA for CloudStack Environments.
> 
> Apache CloudStack Bootcamp training courses
> 
> **NEW!** CloudStack 4.2.1 training<http://shapeblue.com/cloudstack-training/>
> 28th-29th May 2014, Bangalore. 
> Classromm<http://shapeblue.com/cloudstack-training/>
> 16th-20th June 2014, Region A. Instructor led, 
> On-line<http://shapeblue.com/cloudstack-training/>
> 23rd-27th June 2014, Region B. Instructor led, 
> On-line<http://shapeblue.com/cloudstack-training/>
> 15th-20th September 2014, Region A. Instructor led, 
> On-line<http://shapeblue.com/cloudstack-training/>
> 22nd-27th September 2014, Region B. Instructor led, 
> On-line<http://shapeblue.com/cloudstack-training/>
> 1st-6th December 2014, Region A. Instructor led, 
> On-line<http://shapeblue.com/cloudstack-training/>
> 8th-12th December 2014, Region B. Instructor led, 
> On-line<http://shapeblue.com/cloudstack-training/>
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue is a registered 
> trademark.
> 

Re: OpenSSL vunerability (bleedheart)

[John Kinsella]

Folks - we’re aware of the OpenSSL issue, and are working with vendors to 
release mitigation instructions for ACS.

Hoping to have something out later this evening.

John

On Apr 8, 2014, at 8:12 AM, Paul Angus 
mailto:paul.an...@shapeblue.com>> wrote:

A vulnerability has been found in OpenSSL

http://www.bit-tech.net/news/bits/2014/04/08/openssl-heartbleed/1

Affected are OpenSSL versions 1.0.1 and 1.0.2-beta, which include such releases 
as
Debian Wheezy, Ubuntu 12.04.4 LTS, Centos 6.5, Fedora 18, OpenBSD 5.3, FreeBSD 
8.4, NetBSD 5.0.2 and OpenSUSE 12.2.

It is fixed in OpenSSL 1.0.1g

>From https://bugzilla.redhat.com/show_bug.cgi?id=1084875#c9

"Statement:
This issue did not affect the versions of openssl as shipped with Red Hat 
Enterprise Linux 5 and Red Hat Enterprise Linux 6.4 and earlier. This issue 
does affect Red Hat Enterprise Linux 6.5, Red Hat Enterprise Virtualization 
Hypervisor 6.5, and Red Hat Storage 2.1, which provided openssl 1.0.1e."

XenServer 6.2 SP1 uses the native CentOS OpenSSL RPM without modification 
version (OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008) so is unaffected.



Regards,

Paul Angus
Senior Consultant / Cloud Architect

S: +44 20 3603 0540 | M: +447711418784 | 
T: @CloudyAngus
paul.an...@shapeblue.com | 
www.shapeblue.com | 
Twitter:@shapeblue
ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
28th-29th May 2014, Bangalore. 
Classromm
16th-20th June 2014, Region A. Instructor led, 
On-line
23rd-27th June 2014, Region B. Instructor led, 
On-line
15th-20th September 2014, Region A. Instructor led, 
On-line
22nd-27th September 2014, Region B. Instructor led, 
On-line
1st-6th December 2014, Region A. Instructor led, 
On-line
8th-12th December 2014, Region B. Instructor led, 
On-line

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

REMINDER please send security issues to security@

[John Kinsella]

Folks - in the last week or three we’ve had 2 Jira issues created for 
security-related issues. In both cases, they seem to be false-positives, 
luckily.

If you think you have found a security issue in ACS, please email 
secur...@cloudstack.apache.org.

This gives us a chance to investigate and create patches, and give the 
community the best shot of minimizing malicious groups leveraging 
vulnerabilities.

More info about reporting security issues and our response process can be found 
at [1]

John
1: https://cloudstack.apache.org/security.html

Re: Still need SSVM SSL config docs

[John Kinsella]

Thx!

On Mar 25, 2014, at 11:50 AM, Amogh Vasekar 
mailto:amogh.vase...@citrix.com>> wrote:

Hi,

I have some info on :
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes#
RealhostIPchanges-SSVM , which gives pointers on updating the parameter
and tips on how to generate the correct certificate. I will submit a pull
request based on similar lines as console proxy soon.

Thanks,
Amogh

On 3/24/14 11:32 PM, "John Kinsella"  wrote:

Everyone - I believe we¹re still missing documentation on how to
configure ACS 4.3 to use a user-provided SSL certificate for SSVM file
copies?

Pretty sure I know the answer, so consider this a request for that
documentation, at least in wiki form.

I¹ve submitted a pull request for updates to the console proxy docs in
the admin guide.

I¹ve got a blog post in draft format that I¹d like to send out tomorrow,
would love to be able to link to the SSVM configuration steps as well.

John


Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>

Still need SSVM SSL config docs

[John Kinsella]

Everyone - I believe we’re still missing documentation on how to configure ACS 
4.3 to use a user-provided SSL certificate for SSVM file copies?

Pretty sure I know the answer, so consider this a request for that 
documentation, at least in wiki form.

I’ve submitted a pull request for updates to the console proxy docs in the 
admin guide.

I’ve got a blog post in draft format that I’d like to send out tomorrow, would 
love to be able to link to the SSVM configuration steps as well.

John

Re: Simulator Component under Jira

[John Kinsella]

done

On Mar 21, 2014, at 1:18 AM, Santhosh Edukulla  
wrote:

> Team,
> 
> Currently, it seems we don't have a component by name Simulator under jira, 
> This component can be used for any changes we do and issues raised against 
> simulator.
> 
> Please, some body with permissions can add it. 
> 
> 
> Thanks!
> Santhosh

Re: Review Request 12228: static resource compression

[John Kinsella]

Canya tell us a little more about the test you’re doing? What URL are you 
fetching, how many times etc. Just curious to tinker myself this weekend if I 
have some time. :)

On Mar 21, 2014, at 1:07 PM, Laszlo Hornyak 
mailto:laszlo.horn...@gmail.com>> wrote:


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12228/#review38181
---


https://docs.google.com/spreadsheet/ccc?key=0ApMkIX1Ygx8zdHhqV2RETy05SDU1WER3Z2JEN3ktZHc&usp=sharing

Comparison of 3 configurations, the dynamic compression solution is the last 
one. This test was conducted in a VM with 2 vCPU and 4 GB RAM on a
AMD E2-1800.


- Laszlo Hornyak


On March 20, 2014, 7:53 p.m., Laszlo Hornyak wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12228/
---

(Updated March 20, 2014, 7:53 p.m.)


Review request for cloudstack, Brian Federle, Darren Shepherd, and Prasanna 
Santhanam.


Repository: cloudstack-git


Description
---

CloudStack at first use downloads some 3.5 MB of css and javascript to the 
client. With a weak internet connection, this might take a long time. With gzip 
compression content can be compressed to 850 KB.

This version of the patch uses a custom plugin to compress static resources, so 
that no dynamic compression is needed at runtime. When the static resource 
servlet notices that there is gzipped version of the resource and the client 
accepts gzipped content, then it is going to send the gziped version, while 
still respects http caching.


Diffs
-

 client/WEB-INF/web.xml 1af38e1
 client/pom.xml d8dbde7
 server/src/com/cloud/servlet/StaticResourceServlet.java PRE-CREATION
 server/test/com/cloud/servlet/StaticResourceServletTest.java PRE-CREATION

Diff: https://reviews.apache.org/r/12228/diff/


Testing
---

yes, tested with firefox and chrome


Thanks,

Laszlo Hornyak




Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: Review Request 12228: static resource compression

[John Kinsella]

Laszlo, can you reference any other open source projects that have similar 
solutions to this issue? Anything I’ve read states dynamic compression in 
tomcat/httpd/nginx does not add significant CPU overhead.

On Mar 20, 2014, at 12:53 PM, Laszlo Hornyak 
mailto:laszlo.horn...@gmail.com>> wrote:


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12228/
---

(Updated March 20, 2014, 7:53 p.m.)


Review request for cloudstack, Brian Federle, Darren Shepherd, and Prasanna 
Santhanam.


Changes
---

spaces


Repository: cloudstack-git


Description
---

CloudStack at first use downloads some 3.5 MB of css and javascript to the 
client. With a weak internet connection, this might take a long time. With gzip 
compression content can be compressed to 850 KB.

This version of the patch uses a custom plugin to compress static resources, so 
that no dynamic compression is needed at runtime. When the static resource 
servlet notices that there is gzipped version of the resource and the client 
accepts gzipped content, then it is going to send the gziped version, while 
still respects http caching.


Diffs (updated)
-

 client/WEB-INF/web.xml 1af38e1
 client/pom.xml d8dbde7
 server/src/com/cloud/servlet/StaticResourceServlet.java PRE-CREATION
 server/test/com/cloud/servlet/StaticResourceServletTest.java PRE-CREATION

Diff: https://reviews.apache.org/r/12228/diff/


Testing
---

yes, tested with firefox and chrome


Thanks,

Laszlo Hornyak


Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: Resetting a VM is broken?

[John Kinsella]

Mike - There is a way to restore disks in destroyed state before they are 
expunged. It requires shutting down management server, modifying database 
directly, and keeping a good stock of potential offerings near your data 
recovery shrine.

I’m going to be covering this in my CCC Denver talk.

John

On Mar 19, 2014, at 9:59 PM, Mike Tutkowski 
mailto:mike.tutkow...@solidfire.com>> wrote:

Please correct me if I'm wrong, but there does not appear to be a way to
"save" the old root disk once it has gone into the Destroy state in this
situation, is there?

In other words, the new root disk is created, the old is put into the
Destroy state, and the old will get deleted at the next clean-up cycle...no
chance to restore that volume (even for use as a data disk).


On Wed, Mar 19, 2014 at 10:33 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

OK, I went back an re-ran my test.

I see how this works now.

I was aware that volumes in the Destroy state get expunged by a background
thread at some point; however, what tricked me here is that my "old" root
disk no longer showed up in the Storage tab of the GUI.

When I looked in the volumes table, though, I saw that that disk was in
the Destroy state.

I speed up the frequency of the clean-up background thread to run once
every minute and I saw the old root disk got put into the Expunged state
(as you'd expect, it was no longer present in the SR).


On Wed, Mar 19, 2014 at 7:06 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

Yeah, usually "reset" (for hypervisors) means "shut down the VM and
re-start it."


On Wed, Mar 19, 2014 at 6:22 PM, Marcus 
mailto:shadow...@gmail.com>> wrote:

+1 to reset being a bad verb for this. It's too late now, however.

On Wed, Mar 19, 2014 at 6:22 PM, Marcus 
mailto:shadow...@gmail.com>> wrote:
The storage gets marked as 'Destroy' state. Then it goes to
'Expunging' when the storage cleanup interval occurs. I've actually
thought about leveraging that for data disks, the current delete data
disk immediately cleans up the disk, when we could create an api call
that just moves the data disk to destroy state. Then there'd actually
be room for an 'undo' operation where the state could be moved back to
Ready, so long as the cleanup hasn't occurred.

On Wed, Mar 19, 2014 at 4:43 PM, Nitin Mehta 
mailto:nitin.me...@citrix.com>>
wrote:
Please feel free to open a documentation bug on JIRA if the info
doesn't
exist.

On 19/03/14 3:16 PM, "Mike Tutkowski" 
mailto:mike.tutkow...@solidfire.com>>
wrote:

Thanks for that background-cleanup info. I was not aware of that.

I'll probably take a look into it and see how that works.


On Wed, Mar 19, 2014 at 4:13 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

CS destroys the Root volume in CS DB, then its up to the storage
pool
cleanup task to clean it up on the backend. This is a background
task
running every storage.cleanup.interval seconds.

For how long do you see the volume being present on the SR?

On 3/19/14, 3:03 PM, "Mike Tutkowski" 
mailto:mike.tutkow...@solidfire.com>

wrote:

OK, sounds good; however, if this is desired behavior, does anyone
know
why
we abandon the old root disk in the XenServer SR? It seems that
CloudStack
"forgets" about it and it just stays in the SR taking up space.

Do people think it should be deleted?


On Wed, Mar 19, 2014 at 3:49 PM, Nitin Mehta <
nitin.me...@citrix.com>
wrote:

I think that's what it is supposed to do. It discards the old
root
disk
and creates a fresh root disk for the vm and in case an optional
field
template id is passed in the root disk is created from this new
template
id.
The api name is restoreVirtualMachine. Please check that the UI
is
internally invoking this api

Thanks,
-Nitin

On 19/03/14 1:55 PM, "Mike Tutkowski" <
mike.tutkow...@solidfire.com>
wrote:

Hi,

I noticed today while running through some test cases for 4.4
that
resetting a VM does not work as expected.

Instead of the typical stop and re-start behavior where the VM
is
booted
back up using the same root disk, the VM gets a new root disk
when
it
is
booted back up.

Can anyone confirm this finding for me with his or her setup?

Thanks!

--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*




--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*




--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com

Re: RealHostIp

[John Kinsella]

+1 on avoiding 8.8.8.8. Nothing good comes from google knowing your dns 
resolution history...

(or whatever other free dns resolvers)

On Mar 19, 2014, at 2:08 PM, Nux!  wrote:

> On 19.03.2014 19:37, Alex Hitchins wrote:
>> It's my DNS, it just won't play ball with this one domain.
>> I will try changing it to 8.8.8.8 and see if that makes any
>> different. My suspicion is with BT and their 'smart' filtering.
>> Thanks to all those who checked for me.
> 
> Alex,
> 
> Had many issues with BT's DNS. I ended up running a resolver on 127.0.0.1, 
> probably the best choice and it's easy-peasy.
> I'd avoid 8.8.8.8[1] and all the other "free" nameservers.
> 
> Lucian
> 
> [1] - 
> http://www.zdnet.com/google-free-public-dns-services-were-briefly-corrupted-727401/
> 
> -- 
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: [ANNOUNCE] Change of Apache CloudStack PMC Chair

[John Kinsella]

Chip - your balanced viewpoint has kept ACS moving forward in leaps and bounds. 
I greedily hope you’ll continue to stay involved, no matter what $dayjob says. 
:)

Congrats Hugo - looking forward to another great year!

On Mar 19, 2014, at 1:51 PM, Chip Childers  wrote:

> Per our project bylaws, we are changing our project's chair today!
> 
> Over discussions during the last month the PMC had reached a consensus 
> to recommend to the ASF board that Hugo Trippaers be accepted as the 
> next Apache CloudStack PMC Chair / VP of Apache CloudStack.  As of
> today's ASF board meeting, this has been accepted and made official.
> 
> Please join me in congratulating Hugo in his new role!
> 
> It's been an honor serving the project as it's chair over the last year, 
> and although I regret that my recent contributions have been diminished 
> due to a change in $dayjob, I'm exceptionally proud to be part of this 
> community. Apache CloudStack is amazing software, and the community that 
> has formed around the code since it's donation to the ASF is nothing 
> short of remarkable.
> 
> -chip

Re: RealHostIp

[John Kinsella]

I can’t ping the NS servers, but they do respond to queries…

On Mar 19, 2014, at 2:37 AM, Alex Hitchins  wrote:

> I can't ping RealHostIp, has the service been properly taken down? An 
> NSLOOKUP didn't resolve any nameservers at all.
> 
> Alex
> 
> .
> 
> Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure 
> Support offers the 
> best 24/7 SLA for CloudStack Environments.
> 
> Apache CloudStack Bootcamp training courses
> 
> **NEW!** CloudStack 4.2.1 training
> 18th-19th February 2014, Brazil. 
> Classroom
> 17th-23rd March 2014, Region A. Instructor led, 
> On-line
> 24th-28th March 2014, Region B. Instructor led, 
> On-line
> 16th-20th June 2014, Region A. Instructor led, 
> On-line
> 23rd-27th June 2014, Region B. Instructor led, 
> On-line
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue is a registered 
> trademark.

Re: 4.3 vote

[John Kinsella]

btw, what I’m doing here is based on 
http://svn.apache.org/viewvc/axis/axis2/java/rampart/trunk/pom.xml?r1=1355738&r2=1357818&pathrev=1357818&diff_format=h


On Mar 17, 2014, at 10:34 PM, John Kinsella 
mailto:j...@stratosec.co>> wrote:

>From my last few hours tinkering, this seems like an alternate workaround to 
>the patch I have in review board, for those who don’t want to patch code but 
>need to build RPMs of ACS:

Executed on a virgin AWS ECS instance running 64 bit Amazon Linux:

sudo yum -y update
sudo yum -y install git java-1.7.0-openjdk-devel
git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git
wget 
http://www.dsgnwrld.com/am/maven/maven-3/3.2.1/binaries/apache-maven-3.2.1-bin.tar.gz
tar xvf apache-maven-3.2.1-bin.tar.gz
export PATH=$PATH:~/apache-maven-3.2.1/bin
# select JDK 1.7 when prompted
sudo alternatives --config java
cd cloudstack/
mvn -P deps
mvn clean install -Pawsapi
# The previous step will fail, as things are: Broken. Next lines before the 
next mvn command fix and clean things up:
Edit 
~/.m2/repository/org/apache/rampart/rampart-project/1.5.1/rampart-project-1.5.1.pom,
 remove repositories section
rm -rf ~/.m2/repository/org/apache/rampart/rahas
rm -rf ~/.m2/repository/org/apache/rampart/rampart
rm -rf ~/.m2/repository/org/apache/rampart/rampart-core
rm -rf ~/.m2/repository/org/apache/rampart/rampart-policy
rm -rf ~/.m2/repository/org/apache/rampart/rampart-trust
rm -rf ~/.m2/repository/org/apache/ws
rm -rf ~/.m2/repository/org/apache/santuario
rm -rf ~/.m2/repository/org/apache/axis2
rm -rf ~/.m2/repository/org/slf4j/
rm -rf ~/.m2/repository/org/opensaml/
rm -rf ~/.m2/repository/commons-lang/
rm -rf ~/.m2/repository/bouncycastle/
mvn clean install -Pawsapi

I haven’t run this through functional testing yet, but the results look 
promising.

On Mar 6, 2014, at 4:14 PM, John Kinsella 
mailto:j...@stratosec.co>> wrote:

David was seeing this as well. This is is a documented problem at 
https://issues.apache.org/jira/browse/RAMPART-393.

I just spun up a VM at AWS using a 64 bit amazon linux api. Ran the commands 
below, got same errors:

  1  sudo yum update
  2  yum install git java-1.7.0-openjdk-devel
  3  git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git
  4  wget 
http://www.dsgnwrld.com/am/maven/maven-3/3.2.1/binaries/apache-maven-3.2.1-bin.tar.gz
  5  tar xvf apache-maven-3.2.1-bin.tar.gz
  6  export PATH=$PATH:~/apache-maven-3.2.1/bin/
  7  cd cloudstack/
  8  mvn -P deps
  9  mvn clean install -Pawsapi

I suspect the Citrix devs are sitting behind Nexus or other maven mirror?

John

On Mar 6, 2014, at 3:13 PM, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com><mailto:animesh.chaturv...@citrix.com>>
 wrote:

Folks anyone else seeing this? I want to build RC soon and wanted to confirm if 
this is an issue or not and if so if we can get a fix right away

-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com]
Sent: Thursday, March 06, 2014 1:20 PM
To: 
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>
Subject: RE: 4.3 vote

John,

I could not reproduce this broken build on 4.3 after wiping out my entire
repository.
1.  rm -rf ~/.m2/repository
2. mvn clean install -Pawsapi

My build is successful.

Can someone who is able to reproduce this check this further?

Prachi


[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Apache CloudStack . SUCCESS [1:53.957s] 
[INFO]
Apache CloudStack Maven Conventions Parent  SUCCESS [0.089s] [INFO]
Apache CloudStack Framework - Managed Context . SUCCESS [28.189s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:06.368s] 
[INFO]
Apache CloudStack Framework ... SUCCESS [0.303s] [INFO]
Apache CloudStack Framework - Event Notification .. SUCCESS [27.125s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [5.878s]
[INFO] Apache CloudStack API . SUCCESS [55.346s] 
[INFO]
Apache CloudStack Framework - REST  SUCCESS [16.891s] [INFO]
Apache CloudStack Framework - IPC . SUCCESS [11.845s] [INFO]
Apache CloudStack Cloud Engine  SUCCESS [0.072s] [INFO]
Apache CloudStack Cloud Engine API  SUCCESS [10.641s] [INFO]
Apache CloudStack Core  SUCCESS [30.300s] [INFO] 
Apache
CloudStack Agents .. SUCCESS [22.533s] [INFO] Apache
CloudStack Framework - Clustering .. SUCCESS [8.801s] [INFO] Apache
CloudStack Framework - Jobs  SUCCESS [9.251s] [INFO] Apache
CloudStack Cloud Engine Schema Component ... SUCCESS [39.764s] [INFO]
Apache CloudStack Framework - Event Notification .. SUCCESS [2.761s] [INFO]
Apache CloudStack Cloud Engine Internal Compone

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[John Kinsella]

I’ll be committing the patch to master in the morning unless I hear otherwise.

On Mar 17, 2014, at 2:56 PM, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>> wrote:



-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Monday, March 17, 2014 2:48 PM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Cc: Likitha Shetty; Prachi Damle
Subject: Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

Thanks Sebastien. I had been intending to mail previous committers on the
subdir.

Prachi/Likitha - any comments on https://reviews.apache.org/r/18392/
would be appreciated.
[Animesh] Removing rampart dependency will need testing AWSAPI again, I am 
inclined to track this for 4.3 maintenance or 4.4 release


On Mar 17, 2014, at 12:54 PM, Sebastien Goasguen
mailto:run...@gmail.com><mailto:run...@gmail.com>> wrote:

John, I am copying Likitha and Prachi who worked on awsapi, maybe they
can help

-sebastien

On Mar 17, 2014, at 2:25 PM, John Kinsella
mailto:j...@stratosec.co><mailto:j...@stratosec.co>> wrote:

Before we go to 9th round, let's get
https://issues.apache.org/jira/browse/CLOUDSTACK-6156 resolved.

I'm pretty busy this week, but will see if I can come up with. Just tried doing
a clean awsapi build on a clean AWS instance again and it still fails.


On Mar 12, 2014, at 5:26 PM, Animesh Chaturvedi
mailto:animesh.chaturv...@citrix.com><mailto:animesh.chaturv...@citrix.com>http://citrix.com>>> wrote:

Hi All,



I've created a 4.3.0 release, with the following artifacts up for a

vote:





Git Branch and Commit SH:

https://git-wip-
us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3
Commit: 6a6ec648099553a42f830dcd566eab2452428908



List of changes:

New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248

Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249

Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161

Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162







Source release (checksums and signatures are available at the same

location):

https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/



PGP release keys (signed using 94BE0D7C):

https://dist.apache.org/repos/dist/release/cloudstack/KEYS



Testing instructions are here:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pro
cedure



Vote will be open for 72 hours (Monday evening PST 5:30 PM)



For sanity in tallying the vote, can PMC members please be sure to indicate
"(binding)" with their vote?



[ ] +1  approve

[ ] +0  no opinion

[ ] -1  disapprove (and reason why)



Thanks

Animesh


Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>



Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>


Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>

Re: 4.3 vote

[John Kinsella]

>From my last few hours tinkering, this seems like an alternate workaround to 
>the patch I have in review board, for those who don’t want to patch code but 
>need to build RPMs of ACS:

Executed on a virgin AWS ECS instance running 64 bit Amazon Linux:

sudo yum -y update
sudo yum -y install git java-1.7.0-openjdk-devel
git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git
wget 
http://www.dsgnwrld.com/am/maven/maven-3/3.2.1/binaries/apache-maven-3.2.1-bin.tar.gz
tar xvf apache-maven-3.2.1-bin.tar.gz
export PATH=$PATH:~/apache-maven-3.2.1/bin
# select JDK 1.7 when prompted
sudo alternatives --config java 
cd cloudstack/
mvn -P deps
mvn clean install -Pawsapi
# The previous step will fail, as things are: Broken. Next lines before the 
next mvn command fix and clean things up:
Edit 
~/.m2/repository/org/apache/rampart/rampart-project/1.5.1/rampart-project-1.5.1.pom,
 remove repositories section
rm -rf ~/.m2/repository/org/apache/rampart/rahas
rm -rf ~/.m2/repository/org/apache/rampart/rampart
rm -rf ~/.m2/repository/org/apache/rampart/rampart-core
rm -rf ~/.m2/repository/org/apache/rampart/rampart-policy
rm -rf ~/.m2/repository/org/apache/rampart/rampart-trust
rm -rf ~/.m2/repository/org/apache/ws
rm -rf ~/.m2/repository/org/apache/santuario
rm -rf ~/.m2/repository/org/apache/axis2
rm -rf ~/.m2/repository/org/slf4j/
rm -rf ~/.m2/repository/org/opensaml/
rm -rf ~/.m2/repository/commons-lang/
rm -rf ~/.m2/repository/bouncycastle/
mvn clean install -Pawsapi

I haven’t run this through functional testing yet, but the results look 
promising.

On Mar 6, 2014, at 4:14 PM, John Kinsella  wrote:

> David was seeing this as well. This is is a documented problem at 
> https://issues.apache.org/jira/browse/RAMPART-393.
> 
> I just spun up a VM at AWS using a 64 bit amazon linux api. Ran the commands 
> below, got same errors:
> 
>1  sudo yum update
>2  yum install git java-1.7.0-openjdk-devel
>3  git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git
>4  wget 
> http://www.dsgnwrld.com/am/maven/maven-3/3.2.1/binaries/apache-maven-3.2.1-bin.tar.gz
>5  tar xvf apache-maven-3.2.1-bin.tar.gz
>6  export PATH=$PATH:~/apache-maven-3.2.1/bin/
>7  cd cloudstack/
>8  mvn -P deps
>9  mvn clean install -Pawsapi
> 
> I suspect the Citrix devs are sitting behind Nexus or other maven mirror?
> 
> John
> 
> On Mar 6, 2014, at 3:13 PM, Animesh Chaturvedi 
> mailto:animesh.chaturv...@citrix.com>> wrote:
> 
> Folks anyone else seeing this? I want to build RC soon and wanted to confirm 
> if this is an issue or not and if so if we can get a fix right away
> 
> -Original Message-
> From: Prachi Damle [mailto:prachi.da...@citrix.com]
> Sent: Thursday, March 06, 2014 1:20 PM
> To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
> Subject: RE: 4.3 vote
> 
> John,
> 
> I could not reproduce this broken build on 4.3 after wiping out my entire
> repository.
> 1.  rm -rf ~/.m2/repository
> 2. mvn clean install -Pawsapi
> 
> My build is successful.
> 
> Can someone who is able to reproduce this check this further?
> 
> Prachi
> 
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache CloudStack . SUCCESS 
> [1:53.957s] [INFO]
> Apache CloudStack Maven Conventions Parent  SUCCESS [0.089s] [INFO]
> Apache CloudStack Framework - Managed Context . SUCCESS [28.189s]
> [INFO] Apache CloudStack Utils ... SUCCESS 
> [1:06.368s] [INFO]
> Apache CloudStack Framework ... SUCCESS [0.303s] [INFO]
> Apache CloudStack Framework - Event Notification .. SUCCESS [27.125s]
> [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [5.878s]
> [INFO] Apache CloudStack API . SUCCESS [55.346s] 
> [INFO]
> Apache CloudStack Framework - REST  SUCCESS [16.891s] [INFO]
> Apache CloudStack Framework - IPC . SUCCESS [11.845s] [INFO]
> Apache CloudStack Cloud Engine  SUCCESS [0.072s] [INFO]
> Apache CloudStack Cloud Engine API  SUCCESS [10.641s] [INFO]
> Apache CloudStack Core  SUCCESS [30.300s] [INFO] 
> Apache
> CloudStack Agents .. SUCCESS [22.533s] [INFO] Apache
> CloudStack Framework - Clustering .. SUCCESS [8.801s] [INFO] Apache
> CloudStack Framework - Jobs  SUCCESS [9.251s] [INFO] Apache
> CloudStack Cloud Engine Schema Component ... SUCCESS [39.764s] [INFO]
> Apache CloudStack Framework - Event Notification .. SUCCESS [2.761s] [INFO]
> Apache CloudStack Cloud Engine Internal Components API  SUCCESS [6.01

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[John Kinsella]

Thanks Sebastien. I had been intending to mail previous committers on the 
subdir.

Prachi/Likitha - any comments on https://reviews.apache.org/r/18392/ would be 
appreciated.

On Mar 17, 2014, at 12:54 PM, Sebastien Goasguen 
mailto:run...@gmail.com>> wrote:

John, I am copying Likitha and Prachi who worked on awsapi, maybe they can help

-sebastien

On Mar 17, 2014, at 2:25 PM, John Kinsella 
mailto:j...@stratosec.co>> wrote:

Before we go to 9th round, let’s get 
https://issues.apache.org/jira/browse/CLOUDSTACK-6156 resolved.

I’m pretty busy this week, but will see if I can come up with. Just tried doing 
a clean awsapi build on a clean AWS instance again and it still fails.


On Mar 12, 2014, at 5:26 PM, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com><mailto:animesh.chaturv...@citrix.com>>
 wrote:

Hi All,



I've created a 4.3.0 release, with the following artifacts up for a

vote:





Git Branch and Commit SH:

https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3
Commit: 6a6ec648099553a42f830dcd566eab2452428908



List of changes:

New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248

Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249

Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161

Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162







Source release (checksums and signatures are available at the same

location):

https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/



PGP release keys (signed using 94BE0D7C):

https://dist.apache.org/repos/dist/release/cloudstack/KEYS



Testing instructions are here:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure



Vote will be open for 72 hours (Monday evening PST 5:30 PM)



For sanity in tallying the vote, can PMC members please be sure to indicate 
"(binding)" with their vote?



[ ] +1  approve

[ ] +0  no opinion

[ ] -1  disapprove (and reason why)



Thanks

Animesh


Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>



Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[John Kinsella]

Before we go to 9th round, let’s get 
https://issues.apache.org/jira/browse/CLOUDSTACK-6156 resolved.

I’m pretty busy this week, but will see if I can come up with. Just tried doing 
a clean awsapi build on a clean AWS instance again and it still fails.


On Mar 12, 2014, at 5:26 PM, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>> wrote:

Hi All,



I've created a 4.3.0 release, with the following artifacts up for a

vote:





Git Branch and Commit SH:

https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3
Commit: 6a6ec648099553a42f830dcd566eab2452428908



List of changes:

New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248

Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249

Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161

Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162







Source release (checksums and signatures are available at the same

location):

https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/



PGP release keys (signed using 94BE0D7C):

https://dist.apache.org/repos/dist/release/cloudstack/KEYS



Testing instructions are here:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure



Vote will be open for 72 hours (Monday evening PST 5:30 PM)



For sanity in tallying the vote, can PMC members please be sure to indicate 
"(binding)" with their vote?



[ ] +1  approve

[ ] +0  no opinion

[ ] -1  disapprove (and reason why)



Thanks

Animesh


Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: Release cadence

[John Kinsella]

I am in agreement with my radical CloudStack brother.


On Mar 13, 2014, at 9:42 AM, David Nalley  wrote:

> The RC7 vote thread contained a lot of discussion around release
> cadence, and I figured I'd move that to a thread that has a better
> subject so there is better visibility to list participants who don't
> read every thread.
> 
> When I look at things schedule wise, I see our aims and our reality.
> We have a relatively short development window (in the schedule) and we
> have almost 50% of our time in the schedule allocated to testing.
> (over two months). However, it seems that a lot of testing - or at
> least a lot of testing for  what became blockers to the release didn't
> appear to happen until RCs were kicked out - and that's where our
> schedule has fallen apart for multiple releases. The automated tests
> we have were clean when we issued RCs, so we clearly don't have the
> depth needed from an automated standpoint.
> 
> Two problems, one cultural and one technical. The technical problem is
> that our automated test suite isn't deep enough to give us a high
> level of confidence that we should release. The cultural problem is
> that many of us wait until the release period of the schedule to test.
> 
> What does that have to do with release cadence? Well inherently not
> much; but let me describe my concerns. As a project; the schedule is
> meaningless if we don't follow it; and effectively the release date is
> held hostage. Personally, I do want as few bugs as possible, but it's
> a balancing act where people doubt our ability if we aren't able to
> ship. I don't think it matters if we move to 6 month cycles, if this
> behavior continues, we'd miss the 6 month date as well and push to 8
> or 9 months. See my radical proposition at the bottom for an idea on
> dealing with this.
> 
> I also find myself agreeing with Daan on the additional complexity.
> Increasing the window for release inherently increases the window for
> feature development. As soon as we branch a release, master is open
> for feature development again. This means a potential for greater
> change at each release. Change is a risk to quality; or at least an
> unknown that we again have to test. The greater that quantity of
> change, the greater the potential threat to quality.
> 
> Radical proposition:
> 
> Because we have two problems, of different nature, we are in a
> difficult situation. This is a possible solution, and I'd appreciate
> you reading and considering it.  Feedback is welcome. I propose that
> after we enter the RC stage that we not entertain any bugs as blockers
> that don't have automated test cases associated with them. This means
> that you are still welcome to do manual testing of your pet feature
> and the things that are important to you; during the testing window
> (or anytime really). However, if the automation suite isn't also
> failing then we consider the release as high enough quality to ship.
> This isn't something we can codify, but the PMC can certainly adopt
> this attitude as a group when voting. Which also means that we can
> deviate from it. If you brought up a blocker for release - we should
> be immediately looking at how we can write a test for that behavior.
> This should also mean several other behaviors need to become a valid
> part of our process. We need to ensure that things are well tested
> before allowing a merge. This means we need a known state of master,
> and we need to perform testing that allows us to confirm that a patch
> does no harm. We also need to insist on implementation of
> comprehensive tests for every inbound feature.
> 
> Thoughts, comments, flames, death threats? :)
> 
> --David

Re: [PROPOSAL] Enhance the cloudstack events to include more information

[John Kinsella]

I didn’t see comments from others, but this sounds great to me. More info is 
always better IMHO.

On Mar 11, 2014, at 2:31 AM, Sonal Ojha 
mailto:sonal.o...@sungard.com>> wrote:

Currently the event logged in CloudStack doesn't give detailed information
about the event that has occurred. The information provided in each event
shown on the cloudstack ui doesn't provide specifics, particularly in case
of errors. For example, the message shown on the cloudstack ui is just
"Error while starting Vm. Vm Id: " in case of failure to start a vm ,
which doesnt help much.

I would like to propose some changes to enhance the events to be more
informative. Like:

1) Instead of just showing resource database id in the event details it
should also display resource UUID. Since all the cloudstack apis take input
as resource uuid it would be helpful to see the same on the ui as well.
Like in the quickview mode introduce another field as resource UUID which
would specify the UUID for the resource on which the event occurred.

2) Enhance the events and listEvents API to include the resource UUID so
that it can be queried by the resource UUID as well.

3) Currently, the event description messages are specified in the *Cmd.java
file instead, all of them should be externalize to a resource file. This
would be helpful even for internationalization.

4) Provide more detailed messages in case of error events. Messages such as
"Error while starting VM" are generic to take any action.

These changes could be taken forward in phases, some suggestion like

Phase I -
include 2 and 3 point mentioned above
Phase II -
include 1 and 4 point mentioned above

Thoughts / Suggestions ?

--

Regards,

___

*Sonal Ojha* ● Senior Engineer - Product Developement ● SunGard
Availability Services, India ● Mobile: +91 9922412645●  Email:
sonal.o...@sungard.com ● Website: 
http://www.sungardas.in/

8 Times Winner – BC Service Provider of the Year – 2011, 2010, 2009, 2006,
2005, 2002, 2000, 1999; Finalist – 2008, 2007, 2004, 2001 ● Excellence in
Infrastructure Management – 2010 ● Outstanding Excellence in Business
Continuity – 2008 ● Business Continuity Provider of the Year (BCM Service)
– 2013 BCI Global Awards ● Business Continuity Provider of the Year (BCM
Product) – 2013 BCI India Awards

Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: [DISCUSS] realhostip.com going away

[John Kinsella]

The console technology doesn’t really matter. The encryption is the part of 
concern. You have two choices:

* Shared secret: set up a crypto password in advance, get it onto the CPVM and 
browser in some secure manner. Basically, however you do this you’re 
compromised once somebody sniffs the connection and gets the 
token/password/whatever.
* Public/private key: This is what ACS uses, and as long as you don’t share the 
private key across the internet in a code repository, self sign the key, or use 
a CA authority that’s somewhat competent.

Folks may think this isn’t that big a deal for an internal cloud, but if that 
cloud is running production systems and you’re even vaguely concerned about 
their security, then securing that proxy should be on your mind.

John


On Mar 11, 2014, at 2:32 AM, Paul Angus 
mailto:paul.an...@shapeblue.com>> wrote:

Just thinking out loud;

Would using a secure vnc connection over http achieve the same result as using 
a secure http session - the authentication token is in the initial url anyway..

Regards,

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus
paul.an...@shapeblue.com


Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
18th-19th February 2014, Brazil. 
Classroom
17th-23rd March 2014, Region A. Instructor led, 
On-line
24th-28th March 2014, Region B. Instructor led, 
On-line
16th-20th June 2014, Region A. Instructor led, 
On-line
23rd-27th June 2014, Region B. Instructor led, 
On-line

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: [DISCUSS] realhostip.com going away

[John Kinsella]

I mentioned their response on 3/3. Basically "their position is they think 
they’d be doing the community a disfavor by passing the torch” (quoting my 
previous email, not a direct quote from them but this is their position)

The realhostip cert provides a false sense of security, so I can’t think of a 
reason why I’d want to convince Citrix to change their current course.

Adding the appropriate entries to a provider’s existing DNS server is not a big 
deal and should be easily scriptable. If a provider has several class C blocks 
they have to add, then they REALLY shouldn’t be using realhostip.com, anyways. 

Any energy put into properly setting up a community resolver would be much 
better spent helping others migrate away from realhostip.com.


On Mar 10, 2014, at 7:10 AM, France  wrote:

> Please let us know, what was the Citrixes response to community run 
> realhostip.com service.

Re: [DISCUSS] realhostip.com going away

[John Kinsella]

Folks - just applied Amogh’s patch to 4.3-forward, and back ported that to 
master.

Two steps left on the code side:
 * Need to get this retirement into the 4.3 docs
 * Need to backport this to 4.2

John

On Feb 28, 2014, at 12:27 PM, John Kinsella 
mailto:j...@stratosec.co>> wrote:

Folks: Recently the PMC was informed that the 
realhostip.com<http://realhostip.com> DNS service that ACS currently uses by 
default as part of the console proxy will be disbanded this summer.

We’ve been informed the realhostip service will be shut down June 30th, 2014, 
so we have approximately 4 months to mitigate this.

Here’s my thoughts on how to proceed, in order of priority:

* Make the transition as smooth as possible for current ACS users. Need to 
create clear documentation in the wiki that we can point to on how to migrate 
an existing ACS installation from using realhostip.com<http://realhostip.com> 
to a user’s own certificate and resolver. I see section 16.4.2 in the 4.2 admin 
guide talks about this, but I think we can improve a bit. e.g. the current docs 
don’t make it clear that a wildcard cert is required. Once we have a transition 
guide in place, I intend to announce to users@ and announce@ along with the 
social media paths. This isn’t private, but I’d rather not announce until we 
have a clear, tested easy to follow transition guide to make this as painless 
as possible for folks. I’m working on this and will update after testing.
* If at all possible, I’d really like to get something big and visible into the 
4.3 documentation warning users about this.
* For 4.4, we should no longer be using SSL/realhostip for console proxy. We’re 
expecting some patches to address this, I’ll update this thread once they hit 
and/or a Jira issue is created.

Open to any thoughts/suggestions.

John

Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>

[4.3][Cherry-pick] realhostip changes

[John Kinsella]

Animesh - please pick the commit below from 4.3-forward into 4.3. This is for 
CLOUDSTACK-6204.

2fe7aeea23ddef25224e3e248f0a91513a14811f

John

Re: Review Request 18759: HTTP support for console proxy and making it default

[John Kinsella]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18759/#review36614
---

Ship it!


Ship It!

- John Kinsella


On March 7, 2014, 12:32 a.m., Amogh Vasekar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18759/
> ---
> 
> (Updated March 7, 2014, 12:32 a.m.)
> 
> 
> Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-6204
> 
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-6204
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes to support HTTP mode in Console Proxy, per 
> http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
> realhostip may go away
> 
> More details here : 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/info/ConsoleProxyInfo.java 
> 3439f3d3bfa2e262c48f1d7b1ea4f58522f3fcbe 
>   
> engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
>  a649bb7212308de70c41e2d74de1d865949f1cb7 
>   
> plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
>  52cad3bc7af291e59eabc68e23e09248877e0a81 
>   server/src/com/cloud/configuration/Config.java 
> 473db96059a4367858f9487d901b7cb3a054654a 
>   server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 
> c8769d43349dbc5a3103a00c905f29b7edef0468 
>   server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
> 611550e90832911fb182ad18d93a8a18333f3a35 
>   setup/db/db/schema-421to430.sql 39f58d43822ebbe469d9af433582846a80ce91a0 
>   systemvm/conf/consoleproxy.properties 
> bb452f5823cb2da2e12aa61d762de90e4349e9ee 
> 
> Diff: https://reviews.apache.org/r/18759/diff/
> 
> 
> Testing
> ---
> 
> Tested on local environment by 
> 1. Using HTTP based console proxy
> 2. HTTPS with realhostip domain
> 3. HTTPS with custom domain and self-signed cert
> 4. Secondary storage template download with custom domain and self-signed cert
> 
> 
> Thanks,
> 
> Amogh Vasekar
> 
>

Re: [DISCUSS] realhostip.com going away

[John Kinsella]

Soo…I’d recommend against something like Nux’s suggestion below. I’ve only 
looked briefly at VirtualDNS.java, and it looks fine from a glance, but I’m 
willing to bet I can a) DOS it, and b) use it for a reflection attack. I could 
be wrong, don’t really have time to look closely, but based on it looking like 
the design pattern for a basic UDP server, I wouldn’t recommend the community 
to build a network of those.

4 months is not a huge period of time, but I think if somebody can’t apply a 
patch within 4 months they need to consider if they should be running that 
service. If this was a critical security vulnerability and folks couldn’t patch 
it within a few weeks of notification, I’d have a hard time feeling sorry for 
them.

I do concur that we should back port the patch.

John

On Mar 7, 2014, at 11:19 AM, Nux!  wrote:

> On 07.03.2014 14:55, France wrote:
>> Hi all.
>> Are we going to have a solution for older versions like 4.1.1?
>> I think we can already change that domain to something different
>> currently in settings. Hopefully it's not "hardcoded" anywhere else.
>> Is it?
>> I think it's the right thing to move away from such solution in
>> future versions, but just killing the service with 4 months notice, is
>> not a way to go about in enterprise world. How expensive can it be to
>> keep providing it?
>> If someone needs to take over realhostip.com, we can offer our
>> datacenter resources too.
>> Regards,
>> F.
> 
> It would be interesting to change the NS to 3-4 different Cloudstack 
> users/backers. Even I could run an instance.
> 
> France, here's how to run your own (excuse the formatting, was written in a 
> hurry):
> http://www.nux.ro/archive/2014/03/Run_your_own_realhostip.html
> 
> -- 
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: 4.3 vote

[John Kinsella]

I have a review request sitting at https://reviews.apache.org/r/18392/ - that 
works for me but I don’t know if it’s breaking AWSAPI functionality. Would love 
it if somebody more familiar with that module could test. I’d rather not just 
check that in and see what happens.

Animesh, I know you put a ton of work into these RCs and I hate holding you up, 
but here’s my train of thought: packaging/centos63/package.sh is broken because 
one of the RPMs it attempts to build is for awsapi. No self-respecting 
enterprise (I hope, dream) is going to drop non-packaged (deb, rpm, whatever) 
code on production systems. So if that packaging ability is broken, there’s a 
good chance enterprises can’t use the new code.

Just got an idea to see if Apache’s Sonatype has a valid mirror, and it does, 
at least for some[1]. So I’ll go down that path this AM as well, in case my 
patch above doesn’t work.

John
1: https://repository.apache.org/index.html#nexus-search;quick~mex

On Mar 6, 2014, at 11:04 PM, Animesh Chaturvedi  
wrote:

> Ok so how do we get past this? This should have been pre-existing as 
> dependency has been broken for a long time and I am not sure if this should 
> block our next RC.
> 
>> -Original Message-----
>> From: John Kinsella [mailto:j...@stratosec.co]
>> Sent: Thursday, March 06, 2014 4:14 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.3 vote
>> 
>> David was seeing this as well. This is is a documented problem at
>> https://issues.apache.org/jira/browse/RAMPART-393.
>> 
>> I just spun up a VM at AWS using a 64 bit amazon linux api. Ran the
>> commands below, got same errors:
>> 
>>1  sudo yum update
>>2  yum install git java-1.7.0-openjdk-devel
>>3  git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git
>>4  wget http://www.dsgnwrld.com/am/maven/maven-
>> 3/3.2.1/binaries/apache-maven-3.2.1-bin.tar.gz
>>5  tar xvf apache-maven-3.2.1-bin.tar.gz
>>6  export PATH=$PATH:~/apache-maven-3.2.1/bin/
>>7  cd cloudstack/
>>8  mvn -P deps
>>9  mvn clean install -Pawsapi
>> 
>> I suspect the Citrix devs are sitting behind Nexus or other maven mirror?
>> 
>> John
>> 
>> On Mar 6, 2014, at 3:13 PM, Animesh Chaturvedi
>> mailto:animesh.chaturv...@citrix.com>>
>> wrote:
>> 
>> Folks anyone else seeing this? I want to build RC soon and wanted to
>> confirm if this is an issue or not and if so if we can get a fix right away
>> 
>> -Original Message-
>> From: Prachi Damle [mailto:prachi.da...@citrix.com]
>> Sent: Thursday, March 06, 2014 1:20 PM
>> To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
>> Subject: RE: 4.3 vote
>> 
>> John,
>> 
>> I could not reproduce this broken build on 4.3 after wiping out my entire
>> repository.
>> 1.  rm -rf ~/.m2/repository
>> 2. mvn clean install -Pawsapi
>> 
>> My build is successful.
>> 
>> Can someone who is able to reproduce this check this further?
>> 
>> Prachi
>> 
>> 
>> [INFO] 
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Apache CloudStack . SUCCESS 
>> [1:53.957s] [INFO]
>> Apache CloudStack Maven Conventions Parent  SUCCESS [0.089s] [INFO]
>> Apache CloudStack Framework - Managed Context . SUCCESS [28.189s]
>> [INFO] Apache CloudStack Utils ... SUCCESS 
>> [1:06.368s] [INFO]
>> Apache CloudStack Framework ... SUCCESS [0.303s] [INFO]
>> Apache CloudStack Framework - Event Notification .. SUCCESS [27.125s]
>> [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [5.878s]
>> [INFO] Apache CloudStack API . SUCCESS [55.346s] 
>> [INFO]
>> Apache CloudStack Framework - REST  SUCCESS [16.891s] [INFO]
>> Apache CloudStack Framework - IPC . SUCCESS [11.845s] [INFO]
>> Apache CloudStack Cloud Engine  SUCCESS [0.072s] [INFO]
>> Apache CloudStack Cloud Engine API  SUCCESS [10.641s] [INFO]
>> Apache CloudStack Core  SUCCESS [30.300s] [INFO] 
>> Apache
>> CloudStack Agents .. SUCCESS [22.533s] [INFO] Apache
>> CloudStack Framework - Clustering .. SUCCESS [8.801s] [INFO] Apache
>> CloudStack Framework - Jobs  SUCCESS [9.251s] [INFO] Apache
>> CloudStack Cloud Engine Schema Component ... SUCCESS [39.764s] [INFO]
>> Apache CloudStack Framework

Re: [DISCUSS] realhostip.com going away

[John Kinsella]

So - I’ve browsed around a little after pondering the idea of doing crypto at 
the JS level, but I can’t seem to make the argument and keep a straight face. I 
did find a JS library [1] that would probably work, but still you’re left with 
2 issues: 1) gotta get the library securely to the browser (proper running SSL 
on the management server), and 2) You’d still need a CA to sign the certs that 
run on the console proxy/SSVM [2]. 

So, nix that. It seems like the best way to do this is have security off by 
default, make sure that’s very obvious to new users, and have a guide on how to 
get things production-ready.

Anyways - we almost have the patch ready, Amogh and I have gone back/forth on 
the review once or twice, once we get I think just one more issue straightened 
out we’re good.

John
1: https://github.com/digitalbazaar/forge
2: Ya know…we could run a CA on the management server….

On Mar 6, 2014, at 4:53 PM, Kelven Yang  wrote:

> 
> 
> On 3/2/14, 8:15 AM, "Paul Angus"  wrote:
> 
>> There are a few issues with the current console proxy setup, not least of
>> which is the need to have internet access to resolve realhostip.com in
>> the first place - so console proxy can't work if you don't have internet
>> access on your client.  I have configured alternative realhostip.com
>> setups for clients - and quite a lot of work goes into creating the
>> infrastructure (and certs) to support changing to a user managed
>> certificate.
>> 
>> Sooo, is it at all possible to secure communications with the console
>> proxy, without having to rely on ANY outside entity?
> 
> 
> console proxy client is based on AJAX channel provided by browser via
> Javascript engine, which leaves the security option to be pretty much on
> HTTPS, and it requires a server certificate to start with. So we don¹t
> have many choices here.
> 
> -Kelven
> 
> 
>> 
>> Testing alone is going to be a pain, if a full ssl cert setup is required
>> to use console proxy..
>> 
>> Regards
>> 
>> Paul Angus
>> Cloud Architect
>> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
>> paul.an...@shapeblue.com
>> 
>> -Original Message-
>> From: Amogh Vasekar [mailto:amogh.vase...@citrix.com]
>> Sent: 28 February 2014 23:05
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] realhostip.com going away
>> 
>> 
>> 
>> On 2/28/14 2:03 PM, "Nux!"  wrote:
>> 
>>> There's also the problem of the certificate. It comes bundled in ACS as
>>> far as I can tell.. When does it expire?
>> 
>> notBefore=Feb  3 03:30:40 2012 GMT
>> notAfter=Feb  7 05:11:23 2017 GMT
>> 
>> Need Enterprise Grade Support for Apache CloudStack?
>> Our CloudStack Infrastructure
>> Support offers
>> the best 24/7 SLA for CloudStack Environments.
>> 
>> Apache CloudStack Bootcamp training courses
>> 
>> **NEW!** CloudStack 4.2.1
>> training
>> 18th-19th February 2014, Brazil.
>> Classroom
>> 17th-23rd March 2014, Region A. Instructor led,
>> On-line
>> 24th-28th March 2014, Region B. Instructor led,
>> On-line
>> 16th-20th June 2014, Region A. Instructor led,
>> On-line
>> 23rd-27th June 2014, Region B. Instructor led,
>> On-line
>> 
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views
>> or opinions expressed are solely those of the author and do not
>> necessarily represent those of Shape Blue Ltd or related companies. If
>> you are not the intended recipient of this email, you must neither take
>> any action based upon its contents, nor copy or show it to anyone. Please
>> contact the sender if you believe you have received this email in error.
>> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>> Services India LLP is a company incorporated in India and is operated
>> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>> a company incorporated in Brasil and is operated under license from Shape
>> Blue Ltd. ShapeBlue is a registered trademark.
> 

Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: 4.3 vote

[John Kinsella]

David was seeing this as well. This is is a documented problem at 
https://issues.apache.org/jira/browse/RAMPART-393.

I just spun up a VM at AWS using a 64 bit amazon linux api. Ran the commands 
below, got same errors:

1  sudo yum update
2  yum install git java-1.7.0-openjdk-devel
3  git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git
4  wget 
http://www.dsgnwrld.com/am/maven/maven-3/3.2.1/binaries/apache-maven-3.2.1-bin.tar.gz
5  tar xvf apache-maven-3.2.1-bin.tar.gz
6  export PATH=$PATH:~/apache-maven-3.2.1/bin/
7  cd cloudstack/
8  mvn -P deps
9  mvn clean install -Pawsapi

I suspect the Citrix devs are sitting behind Nexus or other maven mirror?

John

On Mar 6, 2014, at 3:13 PM, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>> wrote:

Folks anyone else seeing this? I want to build RC soon and wanted to confirm if 
this is an issue or not and if so if we can get a fix right away

-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com]
Sent: Thursday, March 06, 2014 1:20 PM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Subject: RE: 4.3 vote

John,

I could not reproduce this broken build on 4.3 after wiping out my entire
repository.
1.  rm -rf ~/.m2/repository
2. mvn clean install -Pawsapi

My build is successful.

Can someone who is able to reproduce this check this further?

Prachi


[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Apache CloudStack . SUCCESS [1:53.957s] 
[INFO]
Apache CloudStack Maven Conventions Parent  SUCCESS [0.089s] [INFO]
Apache CloudStack Framework - Managed Context . SUCCESS [28.189s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:06.368s] 
[INFO]
Apache CloudStack Framework ... SUCCESS [0.303s] [INFO]
Apache CloudStack Framework - Event Notification .. SUCCESS [27.125s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [5.878s]
[INFO] Apache CloudStack API . SUCCESS [55.346s] 
[INFO]
Apache CloudStack Framework - REST  SUCCESS [16.891s] [INFO]
Apache CloudStack Framework - IPC . SUCCESS [11.845s] [INFO]
Apache CloudStack Cloud Engine  SUCCESS [0.072s] [INFO]
Apache CloudStack Cloud Engine API  SUCCESS [10.641s] [INFO]
Apache CloudStack Core  SUCCESS [30.300s] [INFO] 
Apache
CloudStack Agents .. SUCCESS [22.533s] [INFO] Apache
CloudStack Framework - Clustering .. SUCCESS [8.801s] [INFO] Apache
CloudStack Framework - Jobs  SUCCESS [9.251s] [INFO] Apache
CloudStack Cloud Engine Schema Component ... SUCCESS [39.764s] [INFO]
Apache CloudStack Framework - Event Notification .. SUCCESS [2.761s] [INFO]
Apache CloudStack Cloud Engine Internal Components API  SUCCESS [6.014s]
[INFO] Apache CloudStack Server .. SUCCESS [1:23.722s] 
[INFO]
Apache CloudStack Usage Server  SUCCESS [9.872s] [INFO]
Apache XenSource XAPI . SUCCESS [17.003s] [INFO] 
Apache
CloudStack Cloud Engine Orchestration Component  SUCCESS [16.774s]

[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.100s] 
...
[INFO] Apache CloudStack Client UI ... SUCCESS [35.094s] 
[INFO]
Apache CloudStack Console Proxy - RDP Client .. SUCCESS [24.447s] [INFO]
Apache CloudStack Console Proxy ... SUCCESS [0.120s] [INFO]
Apache CloudStack Console Proxy - Server .. SUCCESS [6.431s] [INFO]
Apache CloudStack Framework - QuickCloud .. SUCCESS [0.577s] [INFO]
Apache CloudStack AWS API Bridge .. SUCCESS [4:57.758s] [INFO] 


[INFO] BUILD SUCCESS
[INFO] 

-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Wednesday, March 05, 2014 11:51 AM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Subject: Re: 4.3 vote

The dependency's actually been broken for a very long time, apparently. On
a clean box with no maven repository cache (rm -rf ~/.m2/repository),
awsapi (and therefore RPMs) will not build.

It looks like Noa saw similar issue in
42f3804fbdde7bfe4f3676ef0c18a54dfe95354c, but I'm still seeing issues.

John

On Mar 5, 2014, at 11:10 AM, Animesh Chaturvedi
mailto:animesh.chaturv...@citrix.com><mailto:animesh.chaturv...@citrix.com>>
wrote:

John when was the dependency broken? Are you not able to build AWSAPI?

-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Wednesday, March 05, 2014 11:00 AM
To: 
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@

Re: apidocs build failure

[John Kinsella]

Can’t quite tell if that’s the same as what I was seeing - haven’t tried for a 
few days http://markmail.org/thread/6drub4m2xgrgtfxt

On Mar 6, 2014, at 2:12 PM, Alex Hitchins 
mailto:alex.hitch...@shapeblue.com>> wrote:

Just trying a build against 4.3 (not 4.3-forward) and I get the following error:

[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec 
(compile) on project cloud-apidoc: Command execution failed. Process exited 
with an error: 2 (Exit value: 2) -> [Help 1]

Anyone else seen this issue? I don't know what I'm doing wrong, nothing is 
building for me!


Regards,

Alex Hitchins

D: +44 1892 523 587 | S: +44 20 3603 0540 | M: 
+44 7788 423 969

ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
18th-19th February 2014, Brazil. 
Classroom
17th-23rd March 2014, Region A. Instructor led, 
On-line
24th-28th March 2014, Region B. Instructor led, 
On-line
16th-20th June 2014, Region A. Instructor led, 
On-line
23rd-27th June 2014, Region B. Instructor led, 
On-line

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: Review Request 18759: HTTP support for console proxy and making it default

[John Kinsella]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18759/#review36376
---



core/src/com/cloud/info/ConsoleProxyInfo.java
<https://reviews.apache.org/r/18759/#comment67322>

You're now fixing whitespace issues, instead of adding them. :)

Please leave formatting corrections for a separate review or commit, 
they're not related to this bug.

Sorry, I'm a stickler on mixing formatting changes with logic changes. 
Makes the patch less readable.



server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java
<https://reviews.apache.org/r/18759/#comment67323>

Pull this set of include re-ordering from the patch please. Not a logic 
change, confusing.



setup/db/db/schema-421to430.sql
<https://reviews.apache.org/r/18759/#comment67324>

1) Why 2 subqueries on these 2 updates? Shouldn't just...

UPDATE `cloud`.`configuration` 
SET `value` = CONCAT("*.",(SELECT `value` FROM `cloud`.`configuration` 
WHERE `name`="secstorage.ssl.cert.domain")) 
WHERE `name`="secstorage.ssl.cert.domain";

work?

2) What happens here if a install already has changed away from 
realhostip.com?


- John Kinsella


On March 5, 2014, 8:47 p.m., Amogh Vasekar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18759/
> ---
> 
> (Updated March 5, 2014, 8:47 p.m.)
> 
> 
> Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-6204
> 
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-6204
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes to support HTTP mode in Console Proxy, per 
> http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
> realhostip may go away
> 
> More details here : 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/info/ConsoleProxyInfo.java 
> 3439f3d3bfa2e262c48f1d7b1ea4f58522f3fcbe 
>   
> engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
>  a649bb7212308de70c41e2d74de1d865949f1cb7 
>   
> plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
>  52cad3bc7af291e59eabc68e23e09248877e0a81 
>   server/src/com/cloud/configuration/Config.java 
> 473db96059a4367858f9487d901b7cb3a054654a 
>   server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 
> c8769d43349dbc5a3103a00c905f29b7edef0468 
>   server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
> 611550e90832911fb182ad18d93a8a18333f3a35 
>   setup/db/db/schema-421to430.sql 39f58d43822ebbe469d9af433582846a80ce91a0 
>   systemvm/conf/consoleproxy.properties 
> bb452f5823cb2da2e12aa61d762de90e4349e9ee 
> 
> Diff: https://reviews.apache.org/r/18759/diff/
> 
> 
> Testing
> ---
> 
> Tested on local environment by 
> 1. Using HTTP based console proxy
> 2. HTTPS with realhostip domain
> 3. HTTPS with custom domain and self-signed cert
> 4. Secondary storage template download with custom domain and self-signed cert
> 
> 
> Thanks,
> 
> Amogh Vasekar
> 
>

Re: 4.3 vote

[John Kinsella]

The dependency’s actually been broken for a very long time, apparently. On a 
clean box with no maven repository cache (rm -rf ~/.m2/repository), awsapi (and 
therefore RPMs) will not build.

It looks like Noa saw similar issue in 
42f3804fbdde7bfe4f3676ef0c18a54dfe95354c, but I’m still seeing issues.

John

On Mar 5, 2014, at 11:10 AM, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>> wrote:

John when was the dependency broken? Are you not able to build AWSAPI?

-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Wednesday, March 05, 2014 11:00 AM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Subject: Re: 4.3 vote

FYI I'm still -1 until CLOUDSTACK-6156 and
https://reviews.apache.org/r/18392/ is addressed.

On Mar 5, 2014, at 10:10 AM, Animesh Chaturvedi
mailto:animesh.chaturv...@citrix.com>> wrote:



-Original Message-
From: sebgoa [mailto:run...@gmail.com]
Sent: Wednesday, March 05, 2014 7:58 AM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Subject: Re: 4.3 vote


On Mar 5, 2014, at 4:54 PM, Nux! mailto:n...@li.nux.ro>> wrote:

On 05.03.2014 15:52, Animesh Chaturvedi wrote:
Working on it now, waiting on 1 last thing for realhostip changes

So, does the realhostip "feature" disappear starting with 4.3?

if that's the case we need to put this on the release notes. Happy to
do so if someone send me the text..
[Animesh] It is really a convenience that we got used to not a
feature. You can specify your own domain name and change the
certificate even now with 4.2 and prior releases. The instructions are
in Admin Guide [1]

Amogh has put a wiki on the changes at [2].


[1]
http://cloudstack.apache.org/docs/en-US//Apache_CloudStack/4.2.0/html/
Admin_Guide/console-proxy.html#change-console-proxy-ssl-certificate-do
main

[2]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+chan
ges




Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro



Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>

Re: 4.3 vote

[John Kinsella]

FYI I’m still -1 until CLOUDSTACK-6156 and https://reviews.apache.org/r/18392/ 
is addressed.

On Mar 5, 2014, at 10:10 AM, Animesh Chaturvedi  
wrote:

> 
> 
>> -Original Message-
>> From: sebgoa [mailto:run...@gmail.com]
>> Sent: Wednesday, March 05, 2014 7:58 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.3 vote
>> 
>> 
>> On Mar 5, 2014, at 4:54 PM, Nux!  wrote:
>> 
>>> On 05.03.2014 15:52, Animesh Chaturvedi wrote:
 Working on it now, waiting on 1 last thing for realhostip changes
>>> 
>>> So, does the realhostip "feature" disappear starting with 4.3?
>> 
>> if that's the case we need to put this on the release notes. Happy to do so 
>> if
>> someone send me the text..
> [Animesh] It is really a convenience that we got used to not a feature. You 
> can specify your own domain name and change the certificate even now with 4.2 
> and prior releases. The instructions are in Admin Guide [1]
> 
> Amogh has put a wiki on the changes at [2]. 
> 
> 
> [1] 
> http://cloudstack.apache.org/docs/en-US//Apache_CloudStack/4.2.0/html/Admin_Guide/console-proxy.html#change-console-proxy-ssl-certificate-domain
> 
> [2] 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes
> 
> 
> 
>> 
>>> 
>>> Lucian
>>> 
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> 
>>> Nux!
>>> www.nux.ro
> 

Re: [DISCUSS] realhostip.com going away

[John Kinsella]

It’s not.

On Mar 5, 2014, at 1:48 AM, Erik Weber 
mailto:terbol...@gmail.com>> wrote:

How is security being handled in HTTP mode?


--
Erik


On Wed, Mar 5, 2014 at 2:43 AM, Amogh Vasekar 
mailto:amogh.vase...@citrix.com>>wrote:

Hello,

I have created a review request at : https://reviews.apache.org/r/18759/
that partially address the issue. It has a link to the wiki describing the
changes in detail.

Thanks,
Amogh

On 3/3/14 8:58 AM, "John Kinsella" 
mailto:j...@stratosec.co>> wrote:

I talked with some of the Citrix folk over the weekendŠtheir position is
they think they¹d be doing the community a disfavor by passing the torch,
so-to-speak, and I agree with them [1].

>From what I understand, the patches that are going to be proposed will
remove HTTPS completely and encrypt over http. That said, I haven¹t seen
anything yet, so until we see something we¹re guessing. I¹m waiting a few
more days to see what¹s proposed.

John
1: I¹m sharing conversations with individuals, so take this as hearsay
not official comment from Citrix.

On Mar 2, 2014, at 8:15 AM, Paul Angus
mailto:paul.an...@shapeblue.com><mailto:paul.an...@shapeblue.com>>
 wrote:

There are a few issues with the current console proxy setup, not least of
which is the need to have internet access to resolve
realhostip.com<http://realhostip.com><http://realhostip.com> in the first place 
- so console
proxy can't work if you don't have internet access on your client.  I
have configured alternative 
realhostip.com<http://realhostip.com><http://realhostip.com> setups
for clients - and quite a lot of work goes into creating the
infrastructure (and certs) to support changing to a user managed
certificate.

Sooo, is it at all possible to secure communications with the console
proxy, without having to rely on ANY outside entity?

Testing alone is going to be a pain, if a full ssl cert setup is required
to use console proxy..

Regards

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
paul.an...@shapeblue.com<mailto:paul.an...@shapeblue.com><mailto:paul.an...@shapeblue.com>

-Original Message-
From: Amogh Vasekar [mailto:amogh.vase...@citrix.com]
Sent: 28 February 2014 23:05
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Subject: Re: [DISCUSS] realhostip.com<http://realhostip.com> going away



On 2/28/14 2:03 PM, "Nux!" mailto:n...@li.nux.ro>> wrote:

There's also the problem of the certificate. It comes bundled in ACS as
far as I can tell.. When does it expire?

notBefore=Feb  3 03:30:40 2012 GMT
notAfter=Feb  7 05:11:23 2017 GMT

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure
Support<http://shapeblue.com/cloudstack-infrastructure-support/> offers
the best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1
training<http://shapeblue.com/cloudstack-training/>
18th-19th February 2014, Brazil.
Classroom<http://shapeblue.com/cloudstack-training/>
17th-23rd March 2014, Region A. Instructor led,
On-line<http://shapeblue.com/cloudstack-training/>
24th-28th March 2014, Region B. Instructor led,
On-line<http://shapeblue.com/cloudstack-training/>
16th-20th June 2014, Region A. Instructor led,
On-line<http://shapeblue.com/cloudstack-training/>
23rd-27th June 2014, Region B. Instructor led,
On-line<http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views
or opinions expressed are solely those of the author and do not
necessarily represent those of Shape Blue Ltd or related companies. If
you are not the intended recipient of this email, you must neither take
any action based upon its contents, nor copy or show it to anyone. Please
contact the sender if you believe you have received this email in error.
Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
Services India LLP is a company incorporated in India and is operated
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
a company incorporated in Brasil and is operated under license from Shape
Blue Ltd. ShapeBlue is a registered trademark.

Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>




Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>