zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norbert Kalmar <nkal...@cloudera.com.INVALID>
Subject Re: Crypto Policy (was: Re: [VOTE] Apache ZooKeeper release 3.5.5 candidate 5)
Date Tue, 30 Apr 2019 11:37:35 GMT
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> 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> 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> 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> 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>
> wrote:
> >>>>
> >>>> Il lun 29 apr 2019, 13:44 Ted Dunning <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>
> 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
> >>>>>>>
> >>>>>>
> >>>>>> 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