+1 ... default of password w/o https has always been a smell for me anyway. unauth by default solves a lot of headaches.
the way the docker install sets up a pre-configured password is kinda nice and/or w a switch to karaf we could look at being able to configure auth etc in the product --a On 21 December 2016 at 12:50, Geoff Macartney < [email protected]> wrote: > +1 to the proposal, as Aled says I liked it during previous discussions. > > Going forward to 0.11 I'd suggest we support just two modes of operation: > unauthenticated out-of-the-box for evaluation, and authenticated with > https and jwt for production, with an easy process to get from the former > to the latter. > > > On Wed, 21 Dec 2016, 11:41 Richard Downer, <[email protected]> wrote: > > Hi Aled, > > +1 to your proposal. In the wider view, many popular software projects are > unauthenticated (or fixed credentials) on a default install, and specific > hardening steps need to be followed before running the software on a > server. > > I think authentication needs a bigger discussion post 0.10.0 - I have > several valid use cases from customers that Brooklyn does not currently > support. > > Thanks > Richard. > > > On 21 December 2016 at 10:59, Aled Sage <[email protected]> wrote: > > > Hi all, > > > > I lean towards us changing the existing behaviour for 0.10.0 (i.e. > > producing an rc4 that fixes it). > > > > It seems risky/complicated to revert to the "pre-JAAS authentication code > > path". If there is another acceptable way, then I'd much prefer that. > > > > **Proposal** > > We disable password authentication entirely, as the default > configuration. > > We ensure steps to configure security are well documented. > > > > As per the very long email thread in [1], this is "Alternative Proposal > 2" > > in my email dated 2016-09-13 15:32. > > > > This got Geoff's agreement (on 2016-09-13 16:25) and also Martin's > > agreement (2016-09-13 16:56). John McCabe pointed out by way of > comparison > > that Jenkins deploys out-of-the-box with no auth (2016-09-08 22:05). > > > > The major benefits I see are: > > > > 1. Solves the immediate problem (i.e. backwards compatibility for > > localhost login with no password). > > 2. Super-simple user experience, including for installing on a VM > > (which currently still requires the horrible step of digging out the > > auto-generated username:password, buried in the log). > > 3. Consistency for localhost + remote (getting-started instructions can > > be simpler, rather than different depending how/where you've > > installed it. This has not been stressed enough in the discussions > > so far.) > > 4. Passwords are a false sense of security when using http (which is > > still the default), given that it would be sent in plain text. > > > > We should also ensure that the vagrant install is consistent (e.g. it no > > longer needs to have an auto-populated username:password in the config > > file, and can instead rely on the default being no password). > > > > **Longer Term** > > For the next release (i.e. 0.11.0), we can continue the discussion for > > what the user experience should be long-term (e.g. on first login, it > > prompts for a username+password to be created automatically). This > includes > > discussion of RPM installs: on `yum install ...`, the user doesn't have a > > chance to modify the defaults in the config file before Brooklyn is > started > > for the first time. > > > > For 0.11.0, we re-visit the default Karaf configuration (which I believe > > will still require the auto-generated username + password (buried in the > > log), both for localhost and remote). > > > > Aled > > > > [1] https://lists.apache.org/thread.html/cf6f467cc63afc9bb7bb75d > > 7396becbd4ea2ac273031d31073f546d2@%3Cdev.brooklyn.apache.org%3E > > > > > > > > On 20/12/2016 16:05, Richard Downer wrote: > > > >> Ok, I can reproduce this behaviour when trying to connect to a Brooklyn > >> instance on localhost. > >> > >> *But...* > >> > >> I've started up a new instance on AWS and I'm connecting to it on port > >> 8081. A username and password is printed to the console on startup, and > I > >> can use those credentials to access the web UI. If I give the wrong > >> password, I am forbidden to access. > >> > >> So it seems that this behaviour is unique to localhost. IMO this is > >> annoying but not a release blocker - but it would be nicer to our new > >> users > >> to have a fix. > >> > >> The Brooklyn startup log says: > >> 2016-12-20 15:54:32,668 INFO Starting Brooklyn web-console with > >> passwordless access on localhost and protected access from any other > >> interfaces (no bind address specified) > >> > >> So it seems that the "passwordless access on localhost" isn't quite > true. > >> In that case I'd go with Svet's suggestion to remove the localhost > >> exception. > >> > >> Richard. > >> > >> On 20 December 2016 at 15:08, Svetoslav Neykov < > >> [email protected]> wrote: > >> > >> // Added DISCUSS tag > >>> > >>> There's a long related [PROPOSAL] thread on the topic - > >>> https://lists.apache.org/thread.html/cf6f467cc63afc9bb7bb75d7396bec > >>> bd4ea2ac273031d31073f546d2@%3Cdev.brooklyn.apache.org%3E < > >>> https://lists.apache.org/thread.html/cf6f467cc63afc9bb7bb75d7396bec > >>> bd4ea2ac273031d31073f546d2@%3Cdev.brooklyn.apache.org%3E> which seems > to > >>> have died off without consensus. > >>> > >>> Anyone want to hazard a guess for how hard to fix BROOKLYN-417? > >>>> > >>> There are two possible fixes. > >>> * Require the autogenerated password - as simple as removing the > >>> isRemoteAddressLocalhost[1] check. > >>> * Don't require a password. That's more complicated. It needs > >>> reverting > >>> to the pre-JAAS authentication code path, using a Filter to do the > >>> authorization. Can't say right now whether we can just get some code > from > >>> git history and plug it in or things have changed considerably, > assuming > >>> JAAS under the hood. > >>> > >>> Svet. > >>> > >>> [1] https://github.com/apache/brooklyn-server/blob/master/ > >>> rest/rest-resources/src/main/java/org/apache/brooklyn/rest/ > >>> security/provider/BrooklynUserWithRandomPasswordSecurityProv > >>> ider.java#L55 > >>> > >>> On 20.12.2016 г., at 16:48, Aled Sage <[email protected]> wrote: > >>>> > >>>> Alex, all, > >>>> > >>>> I've created https://issues.apache.org/jira/browse/BROOKLYN-417 to > >>>> > >>> track this - and have included details from my initial investigation. > >>> > >>>> I'm in two minds about whether it blocks the release. We expect people > >>>> > >>> to quickly move to supplying credentials (rather than Brooklyn > >>> auto-generating a password). However, it does impact the initial user > >>> experience (for those running on localhost, rather than vagrant etc) - > >>> having to supply dummy username:password looks horrible. If we did ship > >>> with this, we should probably update the docs to tell people to > configure > >>> the credentials *before* starting brooklyn for the first time. > >>> > >>>> Anyone want to hazard a guess for how hard to fix BROOKLYN-417? > >>>> > >>>> Aled > >>>> > >>>> > >>>> On 20/12/2016 14:06, Alex Heneveld wrote: > >>>> > >>>>> Hi Devs, > >>>>> > >>>>> -0 ? -1 ? > >>>>> > >>>>> The "bin" build when run locally on a fresh system (no > >>>>> > >>>> brooklyn.properties) > >>> > >>>> requires that a username/password is supplied. It doesn't do any > >>>>> authentication of the local credentials but gives a 401 if not > >>>>> supplied. > >>>>> Specifically: > >>>>> > >>>>> $ curl -v http://localhost:8081/ 2>&1 | grep "< HTTP" > >>>>> < HTTP/1.1 401 Unauthorized > >>>>> > >>>>> $ curl -u anyuser:passwordignored -v http://localhost:8081/ 2>&1 | > >>>>> > >>>> grep "< > >>> > >>>> HTTP" > >>>>> < HTTP/1.1 200 OK > >>>>> > >>>>> I'm inclined to think this should block a release as it will break > any > >>>>> workflow that expects local http to work, and will irritate new users > >>>>> without any security benefits, but I could be talked in to forgiving > >>>>> it. > >>>>> > >>>>> --A > >>>>> > >>>>> > >>>>> On 20 December 2016 at 13:41, Andrea Turli > <andrea.turli@cloudsoftcorp. > >>>>> > >>>> com> > >>> > >>>> wrote: > >>>>> > >>>>> +1 (binding) > >>>>>> > >>>>>> Tested by running Svet's verify script. > >>>>>> > >>>>>> Do a clean extract of source repo for next steps. > >>>>>> > >>>>>> ------------------------------------------- > >>>>>> > >>>>>> Checks successfully completed: > >>>>>> [✓] Download links work. > >>>>>> [✓] Checksums and PGP signatures are valid. > >>>>>> [✓] Expanded source archive matches contents of RC tag. > >>>>>> [✓] Expanded source archive builds and passes tests. > >>>>>> [✓] LICENSE is present and correct. > >>>>>> [✓] NOTICE is present and correct, including copyright date. > >>>>>> [✓] No compiled archives bundled in source archive. > >>>>>> > >>>>>> Additional manual steps done (execute in source distribution folder > >>>>>> apache-brooklyn-0.10.0-src: > >>>>>> * Check for files with invalid headers in source distribution. > There > >>>>>> > >>>>> are > >>> > >>>> already files excluded from RAT checks, do a sanity check. > >>>>>> * Check for binary files in source distribution. Look for files > >>>>>> which > >>>>>> > >>>>> are > >>> > >>>> created/compiled based on other source files in the distribution. > >>>>>> > >>>>> "Primary" > >>> > >>>> binary files like images are acceptable. > >>>>>> > >>>>>> Checks left to do manually with the help of above instructions: > >>>>>> [✓] All files have license headers where appropriate: I relied on > the > >>>>>> > >>>>> rat > >>> > >>>> check when running `mvn clean install` for checking that "all files > >>>>>> > >>>>> have > >>> > >>>> license headers where appropriate". > >>>>>> [-] All dependencies have compatible licenses. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 19 December 2016 at 17:28, Svetoslav Neykov < > >>>>>> [email protected]> wrote: > >>>>>> > >>>>>> Geoff, > >>>>>>> > >>>>>>> I checked the checksums with the release verification script. Is > this > >>>>>>>> > >>>>>>> in > >>>>>> > >>>>>>> source control somewhere? I'll offer this to add to it: > >>>>>>>> > >>>>>>> See https://github.com/apache/brooklyn-dist/pull/65 < > >>>>>>> https://github.com/apache/brooklyn-dist/pull/65> and in particular > >>>>>>> https://github.com/neykov/brooklyn-dist/blob/ > >>>>>>> 9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_broo > >>>>>>> klyn_rc.sh > >>>>>>> > >>>>>> < > >>> > >>>> https://github.com/neykov/brooklyn-dist/blob/ > >>>>>>> 9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_ > >>>>>>> > >>>>>> brooklyn_rc.sh> > >>> > >>>> for an initial implementation of these kind of checks (obviously to be > >>>>>>> expanded where possible). > >>>>>>> > >>>>>>> Svet. > >>>>>>> > >>>>>>> > >>>>>>> On 19.12.2016 г., at 18:17, Geoff Macartney <geoff.macartney@ > >>>>>>>> > >>>>>>> cloudsoftcorp.com> wrote: > >>>>>>> > >>>>>>>> +1 > >>>>>>>> > >>>>>>>> [x] Download links work. > >>>>>>>> [x] Binaries work. > >>>>>>>> [x] Checksums and PGP signatures are valid. > >>>>>>>> [x] Expanded source archive matches contents of RC tag. > >>>>>>>> [x] Expanded source archive builds and passes tests. > >>>>>>>> [x] LICENSE is present and correct. > >>>>>>>> [x] NOTICE is present and correct, including copyright date. > >>>>>>>> [x] All files have license headers where appropriate. > >>>>>>>> [-] All dependencies have compatible licenses. > >>>>>>>> [x] No compiled archives bundled in source archive. > >>>>>>>> [x] I follow this project’s commits list. > >>>>>>>> > >>>>>>>> I deployed the classic tarball and karaf versions to Ubuntu using > >>>>>>>> > >>>>>>> Java > >>> > >>>> 8 > >>>>>> > >>>>>>> and 7, > >>>>>>>> and the RPM to Centos 7, and was able to deploy sample > applications > >>>>>>>> > >>>>>>> to > >>> > >>>> AWS > >>>>>>> > >>>>>>>> and SL. > >>>>>>>> > >>>>>>>> I checked the checksums with the release verification script. Is > >>>>>>>> this > >>>>>>>> > >>>>>>> in > >>>>>> > >>>>>>> source > >>>>>>>> control somewhere? I'll offer this to add to it: > >>>>>>>> > >>>>>>>> function licenses_and_notices () { > >>>>>>>> local filename=$1 > >>>>>>>> local copyright='Copyright 2014-2016 The Apache Software > >>>>>>>> > >>>>>>> Foundation' > >>>>>>> > >>>>>>>> for tarball in `ls *.tar.gz`; do > >>>>>>>> container=$( tar tf $tarball | awk NR==1 ) > >>>>>>>> tar tf $tarball | grep -q ${container}LICENSE > >>>>>>>> tar tf $tarball | grep -q ${container}NOTICE > >>>>>>>> tar xOf $tarball ${container}NOTICE | grep -q > "${copyright}" > >>>>>>>> done > >>>>>>>> } > >>>>>>>> > >>>>>>>> licenses_and_notices > >>>>>>>> > >>>>>>>> Notes: > >>>>>>>> > >>>>>>>> I was able to deploy a WebServer + 3-node Riak demo app to > Softlayer > >>>>>>>> without problem, > >>>>>>>> and didn't see the "hostname is (none)" problem mentioned > previously > >>>>>>>> > >>>>>>> by > >>> > >>>> Svet. > >>>>>>>> > >>>>>>>> I tested https access (with Karaf version) and access to it using > >>>>>>>> > >>>>>>> "br" > >>> > >>>> (from Mac) without > >>>>>>>> observing the crash Svet saw: > >>>>>>>> > >>>>>>>> ./br login https://10.10.10.102:8443 geoff password > >>>>>>>> Get https://10.10.10.102:8443/v1/server/version: x509: cannot > >>>>>>>> > >>>>>>> validate > >>>>>>> > >>>>>>>> certificate for 10.10.10.102 because it doesn't contain any IP > SANs > >>>>>>>> > >>>>>>>> ./br --skipSslChecks login https://10.10.10.102:8443 geoff > >>>>>>>> > >>>>>>> password > >>>>>> > >>>>>>> Connected to Brooklyn version 0.10.0 at > >>>>>>>> https://10.10.10.102:8443 > >>>>>>>> > >>>>>>>> ./br app > >>>>>>>> Id | Name | Status | Location > >>>>>>>> > >>>>>>>> > >>>>>>>> Tested the above on Linux and Mac. I also tried 1000 consecutive > >>>>>>>> > >>>>>>> logins > >>>>>> > >>>>>>> and didn't see the > >>>>>>>> segfault as mentioned in the comment on BROOKLYN-416. I don't know > >>>>>>>> > >>>>>>> why > >>> > >>>> Svet > >>>>>>> > >>>>>>>> is seeing these > >>>>>>>> problems; my own tests would indicate that br is working ok. > Anyone > >>>>>>>> > >>>>>>> else > >>>>>> > >>>>>>> able to say what > >>>>>>>> they are seeing? > >>>>>>>> > >>>>>>>> Caveat: > >>>>>>>> > >>>>>>>> I did see the behaviour that Svet describes on the main.uri on the > >>>>>>>> > >>>>>>> sample > >>>>>> > >>>>>>> applications. > >>>>>>>> I thought hard about whether this should prevent us releasing. On > >>>>>>>> the > >>>>>>>> > >>>>>>> one > >>>>>> > >>>>>>> hand, there > >>>>>>>> is a possible risk of a poor impression on users trying Brooklyn > for > >>>>>>>> > >>>>>>> the > >>>>>> > >>>>>>> first time if > >>>>>>>> its own sample apps appear not to work well. On the other hand > it's > >>>>>>>> > >>>>>>> fairly > >>>>>>> > >>>>>>>> clear just from > >>>>>>>> looking at the URL what network it is on, so it shouldn't really > be > >>>>>>>> > >>>>>>> too > >>> > >>>> confusing. In > >>>>>>>> the end what persuaded me was checking back to 0.9.0, and this > >>>>>>>> > >>>>>>> behaviour > >>>>>> > >>>>>>> was already > >>>>>>>> there, so this is not a regression. Not that that matters as such, > >>>>>>>> > >>>>>>> but > >>> > >>>> as > >>>>>> > >>>>>>> far as I recall > >>>>>>>> there was no feedback on the mailing list about this, so it does > not > >>>>>>>> > >>>>>>> seem > >>>>>> > >>>>>>> to have actually > >>>>>>>> caused a problem for anyone in practice. I'm therefore happy > enough > >>>>>>>> > >>>>>>> to > >>> > >>>> say > >>>>>>> > >>>>>>>> +1. > >>>>>>>> At the same time I think it is something that we should tidy up > for > >>>>>>>> > >>>>>>> the > >>> > >>>> future. > >>>>>>>> > >>>>>>>> Geoff > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Mon, 19 Dec 2016 at 11:51 Svetoslav Neykov < > >>>>>>>> [email protected]> wrote: > >>>>>>>> > >>>>>>>> +1 (binding) > >>>>>>>>> > >>>>>>>>> Caveats: > >>>>>>>>> * hostname on Softlayer-provisioned machines is "(none)" > >>>>>>>>> * On Softlayer App Wizard examples "Template 2: Python Web > >>>>>>>>> Server", > >>>>>>>>> "Template 3: Bash Web Server and Riak Cluster" list the private > IP > >>>>>>>>> > >>>>>>>> for > >>> > >>>> "main.uri" (with no "xxx.public/private" alternatives). It's easy to > >>>>>>>>> > >>>>>>>> think > >>>>>>> > >>>>>>>> that it's not working. If public IP is used it's reachable. Some > of > >>>>>>>>> > >>>>>>>> the > >>>>>> > >>>>>>> items have the sensor propagated to top, but it's still the private > >>>>>>>>> > >>>>>>>> IP > >>> > >>>> * "main.uri" is not propagated to root app (for most examples), > >>>>>>>>> > >>>>>>>> need > >>> > >>>> to > >>>>>>> > >>>>>>>> drill down to first child to get the sensors > >>>>>>>>> * br - getting fatal error sometimes ( > >>>>>>>>> https://issues.apache.org/jira/browse/BROOKLYN-416 < > >>>>>>>>> https://issues.apache.org/jira/browse/BROOKLYN-416>). Not a new > >>>>>>>>> > >>>>>>>> problem > >>>>>> > >>>>>>> it seems. > >>>>>>>>> * br - can't use --skipSslChecks, still getting "Get > >>>>>>>>> https://localhost:8443/v1/server/version: x509: certificate is > >>>>>>>>> > >>>>>>>> valid > >>> > >>>> for > >>>>>>> > >>>>>>>> web-console, not localhost" from Karaf dist. > >>>>>>>>> * If I log in into two localhost ports at the same time I get > >>>>>>>>> CSRF > >>>>>>>>> > >>>>>>>> Token > >>>>>>> > >>>>>>>> errors from the page that got loaded first. Using them one by one > >>>>>>>>> > >>>>>>>> works > >>>>>> > >>>>>>> fine. > >>>>>>>>> > >>>>>>>>> Could be easily convinced that item 2 from above doesn't deserve > a > >>>>>>>>> > >>>>>>>> +1, > >>> > >>>> thoughts? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ------------------- > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Tested by running the verify script from > >>>>>>>>> https://github.com/neykov/brooklyn-dist/blob/ > >>>>>>>>> > >>>>>>>> 9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_ > >>>>>>> > >>>>>> brooklyn_rc.sh > >>> > >>>> < > >>>>>>>>> https://github.com/neykov/brooklyn-dist/blob/ > >>>>>>>>> > >>>>>>>> 9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_ > >>>>>>> > >>>>>> brooklyn_rc.sh> > >>> > >>>> (https://github.com/apache/brooklyn-dist/pull/65 < > >>>>>>>>> https://github.com/apache/brooklyn-dist/pull/65>). > >>>>>>>>> Expanded the -bin & -karaf, running with local > brooklyn.properties. > >>>>>>>>> Deployed the example apps to AWS & Softlayer (with preconfigured > >>>>>>>>> > >>>>>>>> locations). > >>>>>>> > >>>>>>>> Expanded the OS X br client and tried it against Classic (https) & > >>>>>>>>> > >>>>>>>> Karaf > >>>>>> > >>>>>>> (non-https); > >>>>>>>>> > >>>>>>>>> [✓] Download links work. > >>>>>>>>> [✓] Binaries work. > >>>>>>>>> [✓] Checksums and PGP signatures are valid. > >>>>>>>>> [✓] Expanded source archive matches contents of RC tag. > >>>>>>>>> [✓] Expanded source archive builds and passes tests. > >>>>>>>>> [✓] LICENSE is present and correct. > >>>>>>>>> [✓] NOTICE is present and correct, including copyright date. > >>>>>>>>> [✓] All files have license headers where appropriate. > >>>>>>>>> [✓] All dependencies have compatible licenses. > >>>>>>>>> [✓] No compiled archives bundled in source archive. > >>>>>>>>> [-] I follow this project’s commits list. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Svet. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 18.12.2016 г., at 19:14, Aled Sage <[email protected]> > wrote: > >>>>>>>>>> > >>>>>>>>>> +1 (binding) > >>>>>>>>>> > >>>>>>>>>> I downloaded the tar.gz, and ran it on OS X. I deployed > >>>>>>>>>> > >>>>>>>>> TomcatServer > >>> > >>>> to > >>>>>> > >>>>>>> AWS, Softlayer, Openstack (bluebox-london) and Google Compute > >>>>>>>>> > >>>>>>>> Engine. > >>> > >>>> I ran the verify_brooklyn_rc.sh script (see attachment in rc1 > >>>>>>>>>> > >>>>>>>>> vote). > >>> > >>>> I relied on the rat check when running `mvn clean install` for > >>>>>>>>>> > >>>>>>>>> checking > >>>>>> > >>>>>>> that "all files have license headers where appropriate". > >>>>>>>>> > >>>>>>>>>> I checked that each tar.gz in [1] contained a top-level LICENSE > >>>>>>>>>> and > >>>>>>>>>> > >>>>>>>>> NOTICE file (including the text "Copyright 2014-2016 The Apache > >>>>>>>>> > >>>>>>>> Software > >>>>>> > >>>>>>> Foundation"). > >>>>>>>>> > >>>>>>>>>> [-] Download links work. > >>>>>>>>>> [-] Binaries work. > >>>>>>>>>> [x] Checksums and PGP signatures are valid. > >>>>>>>>>> [-] Expanded source archive matches contents of RC tag. > >>>>>>>>>> [x] Expanded source archive builds and passes tests. > >>>>>>>>>> [x] LICENSE is present and correct. > >>>>>>>>>> [x] NOTICE is present and correct, including copyright date. > >>>>>>>>>> [x] All files have license headers where appropriate. > >>>>>>>>>> [-] All dependencies have compatible licenses. > >>>>>>>>>> [x] No compiled archives bundled in source archive. > >>>>>>>>>> [x] I follow this project’s commits list. > >>>>>>>>>> > >>>>>>>>>> Aled > >>>>>>>>>> > >>>>>>>>>> [1] > >>>>>>>>>> > >>>>>>>>> https://dist.apache.org/repos/dist/dev/brooklyn/apache- > >>>>>>>>> > >>>>>>>> brooklyn-0.10.0-rc3 > >>>>>>> > >>>>>>>> On 16/12/2016 12:34, Svetoslav Neykov wrote: > >>>>>>>>>> > >>>>>>>>>>> This is to call for a vote for the release of Apache Brooklyn > >>>>>>>>>>> > >>>>>>>>>> 0.10.0. > >>>>>> > >>>>>>> This release comprises of a source code distribution, and a > >>>>>>>>>>> > >>>>>>>>>> corresponding > >>>>>>>>> > >>>>>>>>>> binary distribution, and Maven artifacts. > >>>>>>>>>>> > >>>>>>>>>>> The source and binary distributions, including signatures, > >>>>>>>>>>> > >>>>>>>>>> digests, > >>> > >>>> etc. can > >>>>>>>>> > >>>>>>>>>> be found at: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> https://dist.apache.org/repos/dist/dev/brooklyn/apache- > >>>>>>>>> > >>>>>>>> brooklyn-0.10.0-rc3 > >>>>>>> > >>>>>>>> The artifact SHA-256 checksums are as follows: > >>>>>>>>>>> > >>>>>>>>>>> 9ae6ec9f6e2356264fd2032d224965d191e5eab5a5346f8a9de5b0527165 > >>>>>>>>>>> 0157 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-1.noarch.rpm > >>>>>>>>> > >>>>>>>>>> b43c1fc20409594d17151d68b550bb17d8ea5a5592e0b7fbdcf489a81ca2 > >>>>>>>>>>> 118e > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-bin.tar.gz > >>>>>>>>> > >>>>>>>>>> cb7df99f024e918c5517097d904a68d9976c5bf913c9dd64edebb6b5b6e5 > >>>>>>>>>>> a89e > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-bin.zip > >>>>>>>>> > >>>>>>>>>> d65d2525507d40fa0b554b13a57190a724213610a7615082d53137b7bab4 > >>>>>>>>>>> b5d5 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-linux.tar.gz > >>>>>>>>> > >>>>>>>>>> 4d13118fca8e02aaf5b4ab3b3f305d139450bcf64d290781609643c4622b > >>>>>>>>>>> 8cb5 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-linux.zip > >>>>>>>>> > >>>>>>>>>> 375eb6a4944a7758dc790a75bd4a0abc782a4ba66af754b4162bbb66a339 > >>>>>>>>>>> 02d8 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-macosx.tar.gz > >>>>>>>>> > >>>>>>>>>> 9d95e0679e603a9184ada88b63b0c4e8f8503eb51677e04ae59f4aa05f45 > >>>>>>>>>>> 4860 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-macosx.zip > >>>>>>>>> > >>>>>>>>>> 502e0999d3612f0eb4027d24312da67a67183fc127074ec815b3c72f5de4 > >>>>>>>>>>> 1d87 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-windows.tar.gz > >>>>>>>>> > >>>>>>>>>> 1e1ec0210e53faaf9ef1d8907275535a197b341df80e0832067967f4075d > >>>>>>>>>>> b191 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-windows.zip > >>>>>>>>> > >>>>>>>>>> a32c65628bf897c66ed8bd820a2ce5268bba52815b46f805795e9b51ac83 > >>>>>>>>>>> 6912 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-karaf.tar.gz > >>>>>>>>> > >>>>>>>>>> 4b840de7ab986ba64ffba4b98748ca87818718ac3e386bb2d978533e4fa3 > >>>>>>>>>>> 5f62 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-karaf.zip > >>>>>>>>> > >>>>>>>>>> 7906b3dba2278c9648f2b340a532d3030536a6a8f1c920311bdcd585a421 > >>>>>>>>>>> 11e8 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-src.tar.gz > >>>>>>>>> > >>>>>>>>>> 4579e5e27c2751b5e8b57bab126ae683aa34aa42d6e13eb6c922951df694 > >>>>>>>>>>> 7b4c > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-src.zip > >>>>>>>>> > >>>>>>>>>> b361ada2d4cc1334e72b44986b96e6302aaa24464252c3782f7b679bfa5d > >>>>>>>>>>> a858 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-vagrant.tar.gz > >>>>>>>>> > >>>>>>>>>> 393df963f6b952ec8c05c1aa0ab0d459037e0972798f17ba7d0221f7e357 > >>>>>>>>>>> 0440 > >>>>>>>>>>> > >>>>>>>>>> *apache-brooklyn-0.10.0-rc3-vagrant.zip > >>>>>>>>> > >>>>>>>>>> The Nexus staging repository for the Maven artifacts is located > >>>>>>>>>>> > >>>>>>>>>> at: > >>> > >>>> > >>>>>>>>>>> https://repository.apache.org/content/repositories/ > >>>>>>>>> > >>>>>>>> orgapachebrooklyn-1034 > >>>>>>> > >>>>>>>> All release artifacts are signed with the following key: > >>>>>>>>>>> > >>>>>>>>>>> https://people.apache.org/keys/committer/svet.asc > >>>>>>>>>>> > >>>>>>>>>>> KEYS file available here: > >>>>>>>>>>> > >>>>>>>>>>> https://dist.apache.org/repos/dist/release/brooklyn/KEYS > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> The artifacts were built from git commit IDs: > >>>>>>>>>>> > >>>>>>>>>>> brooklyn: 1d7ab19ffba2c87e9ad1b037fb217dc7d39506c9 > >>>>>>>>>>> brooklyn-client: 0e870fa15714c5a050bb67d6fa0429ff90a8fa4c > >>>>>>>>>>> brooklyn-dist: dda655c45abab34601a5e62250431ea93fdf1755 > >>>>>>>>>>> brooklyn-docs: d75752725ef6683a0f52e3059ed475dc69872f9e > >>>>>>>>>>> brooklyn-library: 9fbc78cb4a9d1dccdbdbb70a1ee48f2afddfe067 > >>>>>>>>>>> brooklyn-server: 41561635e3bbb0524dbeaae516a26c793174fd93 > >>>>>>>>>>> brooklyn-ui: a6e2e8bccfdd98b4f7155b5be86f5b85149e0f33 > >>>>>>>>>>> All of the above have been tagged as > "apache-brooklyn-0.10.0-rc3" > >>>>>>>>>>> > >>>>>>>>>>> Please vote on releasing this package as Apache Brooklyn > 0.10.0. > >>>>>>>>>>> > >>>>>>>>>>> The vote will be open for at least 72 hours. > >>>>>>>>>>> [ ] +1 Release this package as Apache Brooklyn 0.10.0 > >>>>>>>>>>> [ ] +0 no opinion > >>>>>>>>>>> [ ] -1 Do not release this package because ... > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Thanks! > >>>>>>>>>>> Svet. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> CHECKLIST for reference > >>>>>>>>>>> > >>>>>>>>>>> [ ] Download links work. > >>>>>>>>>>> [ ] Binaries work. > >>>>>>>>>>> [ ] Checksums and PGP signatures are valid. > >>>>>>>>>>> [ ] Expanded source archive matches contents of RC tag. > >>>>>>>>>>> [ ] Expanded source archive builds and passes tests. > >>>>>>>>>>> [ ] LICENSE is present and correct. > >>>>>>>>>>> [ ] NOTICE is present and correct, including copyright date. > >>>>>>>>>>> [ ] All files have license headers where appropriate. > >>>>>>>>>>> [ ] All dependencies have compatible licenses. > >>>>>>>>>>> [ ] No compiled archives bundled in source archive. > >>>>>>>>>>> [ ] I follow this project’s commits list. > >>>>>>>>>>> > >>>>>>>>>> > >>> > > >
