+1, agree with Aled's suggestion. Svet.
> On 21.12.2016 г., at 15:05, Alex Heneveld <[email protected]> > wrote: > > +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. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>> >>> >>
