zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@apache.org>
Subject Re: Crypto Policy (was: Re: [VOTE] Apache ZooKeeper release 3.5.5 candidate 5)
Date Tue, 30 Apr 2019 16:00:21 GMT
I’ve created a Jira to track these enhancements:

https://issues.apache.org/jira/browse/ZOOKEEPER-3375 <https://issues.apache.org/jira/browse/ZOOKEEPER-3375>

Andor



> On 2019. Apr 30., at 13:37, Norbert Kalmar <nkalmar@cloudera.com.INVALID <mailto:nkalmar@cloudera.com.INVALID>>
wrote:
> 
> Hi Flavio,
> 
> When I tested the TLS setup on a single machine, I also had issues, java
> errors. It turns out those error were completely unrelated to the problem,
> namely I didn't have the localhost setup in my hostname file. If I remember
> correctly, I needed to add localhost 127.0.0.1, because I only had the
> machine's name setup there. So it couldn't find "localhost".
> 
> Not entirely sure the solution anymore, but it was definitely something
> with localhost.
> 
> After that, it worked fine for me, but I also used a single key for all
> instances on the machine.
> 
> Regards,
> Norbert
> 
> On Tue, Apr 30, 2019 at 1:29 PM Andor Molnar <andor@apache.org <mailto:andor@apache.org>>
wrote:
> 
>> Hi Flavio,
>> 
>> Works for me on a single machine with the following keystores.
>> Aliases are the hostname of the machine (all the same).
>> 
>> keystore1.jks
>> ~~~~~~~~~~
>> Keystore type: JKS
>> Keystore provider: SUN
>> 
>> Your keystore contains 1 entry
>> 
>> andors-macbook-pro.local, Apr 30, 2019, PrivateKeyEntry,
>> Certificate fingerprint (SHA1):
>> 14:46:5F:92:D9:03:88:7E:C9:0A:95:9E:F5:74:08:F4:27:89:36:9D
>> 
>> keystore2.jks
>> ~~~~~~~~~~
>> Keystore type: JKS
>> Keystore provider: SUN
>> 
>> Your keystore contains 1 entry
>> 
>> andors-macbook-pro.local, Apr 30, 2019, PrivateKeyEntry,
>> Certificate fingerprint (SHA1):
>> 61:11:F3:FC:97:B1:3D:DB:6C:65:11:AE:FB:26:39:C0:4F:8E:A7:F7
>> 
>> keystore3.jks
>> ~~~~~~~~~~
>> Keystore type: JKS
>> Keystore provider: SUN
>> 
>> Your keystore contains 1 entry
>> 
>> andors-macbook-pro.local, Apr 30, 2019, PrivateKeyEntry,
>> Certificate fingerprint (SHA1):
>> E0:84:2A:37:A0:8E:22:67:B3:50:21:43:34:D0:FD:E8:A4:50:C4:3F
>> 
>> 
>> …and a single truststore:
>> 
>> $ keytool -list -keystore truststore.jks
>> Enter keystore password:
>> Keystore type: JKS
>> Keystore provider: SUN
>> 
>> Your keystore contains 4 entries
>> 
>> mycert3, Apr 30, 2019, trustedCertEntry,
>> Certificate fingerprint (SHA1):
>> E0:84:2A:37:A0:8E:22:67:B3:50:21:43:34:D0:FD:E8:A4:50:C4:3F
>> mycert2, Apr 30, 2019, trustedCertEntry,
>> Certificate fingerprint (SHA1):
>> 61:11:F3:FC:97:B1:3D:DB:6C:65:11:AE:FB:26:39:C0:4F:8E:A7:F7
>> mycert1, Apr 30, 2019, trustedCertEntry,
>> Certificate fingerprint (SHA1):
>> 14:46:5F:92:D9:03:88:7E:C9:0A:95:9E:F5:74:08:F4:27:89:36:9D
>> 
>> Aliases (mycert1, mycert2, mycert3) doesn’t matter here, ZooKeeper only
>> checks if the given certificate is included in the truststore or not.
>> 
>> Regards,
>> Andor
>> 
>> 
>> 
>>> On 2019. Apr 30., at 12:48, Andor Molnar <andor@apache.org <mailto:andor@apache.org>>
wrote:
>>> 
>>> Makes sense.
>>> 
>>> I’ve tested it on a single machine with the same cert/key for all
>> instances: keystore / truststore only contained a single entry and it
>> worked fine.
>>> We’ve also tested on multiple instances with multiple keys / instances
>> which also worked fine.
>>> 
>>> Let me give it another go with single machine / multiple certs combo.
>>> 
>>> I might need to modify the docs to emphasize keys must be generated on a
>> per machine basis, not ZK instance.
>>> 
>>> Regards,
>>> Andor
>>> 
>>> 
>>> 
>>>> On 2019. Apr 29., at 16:53, Flavio Junqueira <fpj@apache.org <mailto:fpj@apache.org>>
wrote:
>>>> 
>>>> I'm also +1 for adding a comment to the release notes (thanks for the
>> suggestion, Ted). Updating the readme makes sense, but the release notes
>> will be the main source to indicate that we require a specific or later
>> version of Java from that particular release. My preference would be to
>> update the release notes.
>>>> 
>>>> As for running TLS on a single node, have you been able to do it? I
>> haven't had a chance to look further into it throughout my day, so if
>> anyone has successfully done it and can share some instructions, it would
>> help me. Otherwise, I'll keep investigating once I have a chance. To be
>> specific, I created the keystore, certificate and truststore files
>> according to instructions, but the instructions assume that the aliases are
>> different when it comes to populating the truststore. At that point, I had
>> to get creative and I have tried a couple of options that didn't work.
>> Either way, I think that being able to run locally and documenting is
>> desirable, although not a blocker. If I can get it right, then I can write
>> a gist describing it that we can use as a reference until we properly
>> document it.
>>>> 
>>>> -Flavio
>>>> 
>>>>> On 29 Apr 2019, at 15:42, Andor Molnar <andor@apache.org <mailto:andor@apache.org>>
wrote:
>>>>> 
>>>>> Thanks Flavio for the investigation. I’ll update the README file to
>> include instructions on supported Java 8 versions.
>>>>> I’m wondering if I have to update the admin docs based on your
>> problems running TLS quorum on a single machine.
>>>>> 
>>>>> Andor
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 2019. Apr 29., at 15:06, Enrico Olivelli <eolivelli@gmail.com
<mailto:eolivelli@gmail.com>>
>> wrote:
>>>>>> 
>>>>>> Il lun 29 apr 2019, 13:44 Ted Dunning <ted.dunning@gmail.com <mailto:ted.dunning@gmail.com>>
ha
>> scritto:
>>>>>> 
>>>>>>> Other changes in u211+ substantially improve how Java 8 applications
>> behave
>>>>>>> in containers. I am seeing this more and more with customers.
>>>>>>> 
>>>>>>> Combined with the crypto issues, it might be worth a release
note
>>>>>>> suggesting that if you are going to compile with Java 1.8, you
>> should use a
>>>>>>> recent release at u211 (u212?) Or above.
>>>>>>> 
>>>>>> 
>>>>>> +1 for a note on release docs
>>>>>> 
>>>>>> 
>>>>>> Enrico
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Mon, Apr 29, 2019, 11:43 AM Flavio Junqueira <fpj@apache.org
<mailto:fpj@apache.org>>
>> wrote:
>>>>>>> 
>>>>>>>> I did a bit more research and it turns out that the crypto.policy
>> option
>>>>>>>> was introduced u151:
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> https://www.oracle.com/technetwork/java/javase/8u151-relnotes-3850493.html <https://www.oracle.com/technetwork/java/javase/8u151-relnotes-3850493.html>
>>>>>>>> <
>>>>>>>> 
>>>>>>> 
>> https://www.oracle.com/technetwork/java/javase/8u151-relnotes-3850493.html
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> And started being defined by default with the "unlimited"
option in
>> u161:
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> https://www.oracle.com/technetwork/java/javase/8u161-relnotes-4021379.html
>>>>>>>> <
>>>>>>>> 
>>>>>>> 
>> https://www.oracle.com/technetwork/java/javase/8u161-relnotes-4021379.html
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I have installed a more recent version, 1.8.0_211, and it
builds
>> fine
>>>>>>> (all
>>>>>>>> tests pass consistently for me).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I'm now trying to start an ensemble with ssl enabled locally,
but
>> it is
>>>>>>>> failing for me. It looks like the instructions in the admin
doc
>> assumes
>>>>>>>> different hosts. I need to look more closely into it to determine
>> what
>>>>>>> not
>>>>>>>> is that I'm doing wrong, but in any case, the instructions
do not
>> make it
>>>>>>>> very clear whether one can run locally.
>>>>>>>> 
>>>>>>>> -Flavio
>>>>>>>> 
>>>>>>>>> On 27 Apr 2019, at 19:28, Patrick Hunt <phunt@apache.org>
wrote:
>>>>>>>>> 
>>>>>>>>> Odd. I had done my testing on jdk11/macos which is fine.
>>>>>>>>> 
>>>>>>>>> I just tried jdk8 and 3 times in a row it's failing with:
>>>>>>>>> [ERROR]
>> SaslAuthTest.testZKOperationsAfterClientSaslAuthFailure:176 »
>>>>>>>>> Timeout Failed t...
>>>>>>>>> 
>>>>>>>>> I don't see the error Flavio is seeing. I have never
installed
>> special
>>>>>>>>> crypto libraries, etc... just vanilla jdk.
>>>>>>>>> 
>>>>>>>>> ⌂102% [phunt:~/Downloads/z/apache-zookeeper-3.5.5]
3s $ mvn
>> --version
>>>>>>>>> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
>>>>>>>>> 2019-04-04T12:00:29-07:00)
>>>>>>>>> Maven home: /usr/local/Cellar/maven/3.6.1/libexec
>>>>>>>>> Java version: 1.8.0_201, vendor: Oracle Corporation,
runtime:
>>>>>>>>> 
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/jre
>>>>>>>>> Default locale: en_US, platform encoding: UTF-8
>>>>>>>>> OS name: "mac os x", version: "10.14.4", arch: "x86_64",
family:
>> "mac"
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2019-04-27 10:11:51,635 [myid:] - INFO
>>>>>>>>> [NIOWorkerThread-6:SaslServerCallbackHandler@136] - Setting
>>>>>>>> authorizedID:
>>>>>>>>> super
>>>>>>>>> 2019-04-27 10:11:51,636 [myid:] - INFO
>>>>>>>>> [NIOWorkerThread-6:ZooKeeperServer@1170] - adding SASL
>> authorization
>>>>>>> for
>>>>>>>>> authorizationID: super
>>>>>>>>> 2019-04-27 10:11:51,813 [myid:] - INFO
>>>>>>>>> [SessionTracker:SessionTrackerImpl@163] - SessionTrackerImpl
>> exited
>>>>>>>> loop!
>>>>>>>>> 2019-04-27 10:12:21,596 [myid:] - INFO
>>>>>>>>> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@98] - TEST
METHOD
>> FAILED
>>>>>>>>> testZKOperationsAfterClientSaslAuthFailure
>>>>>>>>> java.util.concurrent.TimeoutException: Failed to connect
to
>> ZooKeeper
>>>>>>>>> server.
>>>>>>>>> at
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> org.apache.zookeeper.test.ClientBase$CountdownWatcher.waitForConnected(ClientBase.java:150)
>>>>>>>>> at
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> org.apache.zookeeper.SaslAuthTest.testZKOperationsAfterClientSaslAuthFailure(SaslAuthTest.java:176)
>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
>>>>>>>>> at
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>>> at
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>>>>>> at
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>>>>>>>> at
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Patrick
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Sat, Apr 27, 2019 at 8:54 AM Enrico Olivelli <
>> eolivelli@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> On my local tests I usually don't get the error because
I am using
>>>>>>>>>> jdk11 and unlimited strength cryptography is enabled
by default
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> https://www.oracle.com/technetwork/java/javase/documentation/jdk11-readme-5097204.html#jce
>>>>>>>>>> 
>>>>>>>>>> In production it depends on the configuration of
SSL, if you
>> require
>>>>>>>>>> strong ciphers/big keys you will have problems, but
the server
>> won't
>>>>>>>>>> start so you will find soon the problem.
>>>>>>>>>> I think this is not a real issue (for production
I mean).
>>>>>>>>>> I see these ways:
>>>>>>>>>> 1) adapt the tests in order to make default jdk8
happy
>>>>>>>>>> 2) tweak the tests enabling "unlimited strenght cryptography"
>> using
>>>>>>>>>> reflection
>>>>>>>>>> 3) just write a line in documentation that says that
in order to
>> make
>>>>>>>>>> tests pass you have to enable the flag
>>>>>>>>>> 
>>>>>>>>>> That flag is deprecated and enabled by default in
modern JREs, so
>> I
>>>>>>>>>> would go for 2) or 3)
>>>>>>>>>> 
>>>>>>>>>> I guess that on  ASF Jenkins if the JDK8 we are using
has the flag
>>>>>>>> turned
>>>>>>>>>> on
>>>>>>>>>> 
>>>>>>>>>> Enrico
>>>>>>>>>> 
>>>>>>>>>> Il giorno sab 27 apr 2019 alle ore 17:48 Andor Molnar
>>>>>>>>>> <andor@apache.org> ha scritto:
>>>>>>>>>>> 
>>>>>>>>>>> I’m running the tests fine without setting
the policy to
>> unlimited:
>>>>>>>>>>> 
>>>>>>>>>>> java version "1.8.0_161"
>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12,
mixed mode)
>>>>>>>>>>> 
>>>>>>>>>>> Have you tried to run it with a more recent version
of Java?
>>>>>>>>>>> 
>>>>>>>>>>> Andor
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On 2019. Apr 27., at 17:33, Andor Molnar
<andor@apache.org>
>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Good catch, thanks Flavio for reporting this.
We need to double
>>>>>>> check
>>>>>>>>>> the tests with Ilya I believe.
>>>>>>>>>>>> 
>>>>>>>>>>>> Having tests failure means that you were
actually able to
>> _build_
>>>>>>>>>> ZooKeeper successfully without changing the crypto
policy setting.
>>>>>>> Have
>>>>>>>> you
>>>>>>>>>> tried to start an ensemble with Quorum TLS by any
chance? That
>> would
>>>>>>> add
>>>>>>>>>> some more color to this issue.
>>>>>>>>>>>> 
>>>>>>>>>>>> This might be just a testing issue.
>>>>>>>>>>>> 
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Andor
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 2019. Apr 27., at 16:09, Flavio Junqueira
<fpj@apache.org>
>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Enrico,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Here is the info you are requesting:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> *Java version*
>>>>>>>>>>>>> 
>>>>>>>>>>>>> $ java -version
>>>>>>>>>>>>> java version "1.8.0_152"
>>>>>>>>>>>>> Java(TM) SE Runtime Environment (build
1.8.0_152-b16)
>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build
25.152-b16, mixed
>> mode)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> *Test case errors*
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I won’t post all of them, I get a good
number of errors:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ================================
>>>>>>>>>>>>> [ERROR] Tests run: 64, Failures: 0, Errors:
16, Skipped: 0,
>> Time
>>>>>>>>>> elapsed: 9.21 s <<< FAILURE! - in
>>>>>>>> org.apache.zookeeper.util.PemReaderTest
>>>>>>>>>>>>> [ERROR]
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> testLoadCertificateFromKeyStore[1](org.apache.zookeeper.util.PemReaderTest)
>>>>>>>>>> Time elapsed: 1.593 s  <<< ERROR!
>>>>>>>>>>>>> java.io.IOException:
>>>>>>>>>> org.bouncycastle.operator.OperatorCreationException:
Illegal key
>> size
>>>>>>> or
>>>>>>>>>> default parameters
>>>>>>>>>>>>> at
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> org.apache.zookeeper.util.PemReaderTest.testLoadCertificateFromKeyStore(PemReaderTest.java:125)
>>>>>>>>>>>>> Caused by: org.bouncycastle.operator.OperatorCreationException:
>>>>>>>>>> Illegal key size or default parameters
>>>>>>>>>>>>> at
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> org.apache.zookeeper.util.PemReaderTest.testLoadCertificateFromKeyStore(PemReaderTest.java:125)
>>>>>>>>>>>>> Caused by: java.security.InvalidKeyException:
Illegal key size
>> or
>>>>>>>>>> default parameters
>>>>>>>>>>>>> at
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> org.apache.zookeeper.util.PemReaderTest.testLoadCertificateFromKeyStore(PemReaderTest.java:125)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [ERROR]
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> testLoadEncryptedPrivateKeyFromKeyStoreWithWrongPassword[1](org.apache.zookeeper.util.PemReaderTest)
>>>>>>>>>> Time elapsed: 0.004 s  <<< ERROR!
>>>>>>>>>>>>> java.lang.Exception: Unexpected exception,
>>>>>>>>>> expected<java.security.GeneralSecurityException>
but
>>>>>>>>>> was<java.io.IOException>
>>>>>>>>>>>>> at
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> org.apache.zookeeper.util.PemReaderTest.testLoadEncryptedPrivateKeyFromKeyStoreWithWrongPassword(PemReaderTest.java:93)
>>>>>>>>>>>>> Caused by: org.bouncycastle.operator.OperatorCreationException:
>>>>>>>>>> Illegal key size or default parameters
>>>>>>>>>>>>> at
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> org.apache.zookeeper.util.PemReaderTest.testLoadEncryptedPrivateKeyFromKeyStoreWithWrongPassword(PemReaderTest.java:93)
>>>>>>>>>>>>> Caused by: java.security.InvalidKeyException:
Illegal key size
>> or
>>>>>>>>>> default parameters
>>>>>>>>>>>>> at
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> org.apache.zookeeper.util.PemReaderTest.testLoadEncryptedPrivateKeyFromKeyStoreWithWrongPassword(PemReaderTest.java:93)
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> ================================
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> *Crypto policy*
>>>>>>>>>>>>> If I uncomment this configuration option:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> # Please see the JCA documentation for
additional information
>> on
>>>>>>>> these
>>>>>>>>>>>>> # files and formats.
>>>>>>>>>>>>> # crypto.policy=unlimited
>>>>>>>>>>>>> 
>>>>>>>>>>>>> in:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> $JAVA_HOME/jre/lib/security/java.security
>>>>>>>>>>>>> 
>>>>>>>>>>>>> then it all works and I get no error
at all. This option
>> controls
>>>>>>>>>> cryptographic strengths according to the documentation,
and is
>> present
>>>>>>>>>> because of crypto regulations in different countries.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> -Flavio
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 27 Apr 2019, at 15:52, Enrico
Olivelli <
>> eolivelli@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Il sab 27 apr 2019, 14:18 Flavio
Junqueira <fpj@apache.org>
>> ha
>>>>>>>>>> scritto:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I have a clarification question
about the RC. To build the
>> RC, I
>>>>>>>>>> had to
>>>>>>>>>>>>>>> enable crypto.policy unlimited
in the jre (I'm using build
>>>>>>>>>> 1.8.0_152-b16).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Flavio
>>>>>>>>>>>>>> What do you mean with 'build' ?
>>>>>>>>>>>>>> Make tests pass?
>>>>>>>>>>>>>> AFAIK we are not using tweaked jdks
in CI builds, so in theory
>>>>>>> there
>>>>>>>>>> is no
>>>>>>>>>>>>>> need.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Can you please share your error?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Enrico
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I'm wondering if this is going to
be an issue for some users
>> as
>>>>>>> this
>>>>>>>>>> option
>>>>>>>>>>>>>>> is related to import/export regulation.
Has anyone looked
>> into it
>>>>>>>>>> and could
>>>>>>>>>>>>>>> clarify it to me, please?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> -Flavio
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 25 Apr 2019, at 15:10,
Andor Molnar <andor@apache.org>
>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> This is the first stable
release of 3.5 branch: 3.5.5. It
>>>>>>> resolves
>>>>>>>>>> 117
>>>>>>>>>>>>>>> issues, including Maven migration,
Quorum TLS, TTL nodes and
>> lots
>>>>>>>>>> of other
>>>>>>>>>>>>>>> performance and stability improvements.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> The full release notes is
available at:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12343268
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> *** Please download, test
and vote by May 3rd 2019, 23:59
>> UTC+0.
>>>>>>>>>> ***
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Source files:
>>>>>>>>>>>>>>>> 
>>>>>>>>>> 
>> https://dist.apache.org/repos/dist/dev/zookeeper/zookeeper-3.5.5-rc5/
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Maven staging repos:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/parent/3.5.5/
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper-jute/3.5.5/
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.5/
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> The release candidate tag
in git to be voted upon:
>>>>>>>>>> release-3.5.5-rc5
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> ZooKeeper's KEYS file containing
PGP keys we use to sign the
>>>>>>>>>> release:
>>>>>>>>>>>>>>>> http://www.apache.org/dist/zookeeper/KEYS
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Should we release this candidate?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message