RE: MD5 in the read path

[Tyagi, Preetika]

Makes sense. Thanks!

-Original Message-
From: Joseph Lynch [mailto:joe.e.ly...@gmail.com] 
Sent: Wednesday, September 26, 2018 9:02 PM
To: dev@cassandra.apache.org
Subject: Re: MD5 in the read path

>
> Thank you all for the response.
> For RandomPartitioner, MD5 is used to avoid collision. However, why is 
> it necessary for comparing data between different replicas? Is it not 
> feasible to use CRC for data comparison?
>
My understanding is that it is not necessary to use MD5 and we can switch out 
the message digest function as long as we have an upgrade path. I believe this 
is the goal of https://issues.apache.org/jira/browse/CASSANDRA-13292.

-Joey

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: MD5 in the read path

[Joseph Lynch]

>
> Thank you all for the response.
> For RandomPartitioner, MD5 is used to avoid collision. However, why is it
> necessary for comparing data between different replicas? Is it not feasible
> to use CRC for data comparison?
>
My understanding is that it is not necessary to use MD5 and we can switch
out the message digest function as long as we have an upgrade path. I
believe this is the goal of
https://issues.apache.org/jira/browse/CASSANDRA-13292.

-Joey

RE: MD5 in the read path

[Tyagi, Preetika]

Thank you all for the response.
For RandomPartitioner, MD5 is used to avoid collision. However, why is it 
necessary for comparing data between different replicas? Is it not feasible to 
use CRC for data comparison?

Thanks,
Preetika

-Original Message-
From: Elliott Sims [mailto:elli...@backblaze.com] 
Sent: Wednesday, September 26, 2018 7:58 PM
To: dev@cassandra.apache.org
Subject: Re: MD5 in the read path

Would xxHash be large enough for digests?  Looks like there's no 128-bit 
version yet, and it seems like 64 bits would be a bit short to avoid accidental 
collisions/matches.  FarmHash128 or MetroHash128 might be a good choice.  Not 
quite as fast as xxHash64, but not far off and still much, much faster than MD5 
and somewhat faster than murmur3. May require some amount of benchmarking, 
since most of the performance comparisons are C and the performance of the Java 
implementations may vary drastically.

Looks like https://issues.apache.org/jira/browse/CASSANDRA-13291 already 
switched to Guava, which probably makes Murmur3_128 easier to switch to than 
the rest, and it may be enough faster than MD5 to be beyond the point of 
diminishing returns anyways.

 (far from an expert, but this thread prompted me to go poking through hash 
options out of curiosity)

On Wed, Sep 26, 2018 at 9:04 PM Joseph Lynch  wrote:

> Michael Kjellman and others (Jason, Sam, et al.) have already done a 
> lot of work in 4.0 to help change the use of MD5 to something more modern 
> [1][2].
> Also I cut a ticket a little while back about the significant 
> performance penalty of using MD5 for digests when doing quorum reads 
> of wide partitions [1]. Given the profiling that Michael has done and 
> the production profiling we did I think it's fair to say that changing 
> the digest from MD5 to
> murmur3 or xxHash would lead to a noticeable performance improvement 
> for quorum reads, perhaps even something like a 2x throughput increase for 
> e.g.
> wide partition workloads.
>
> The hard part is changing the digest hash without breaking older 
> versions, e.g. during a rolling restart you can't have one node give a 
> MD5 hash and the other give a xxHash hash as you'll end up with lots 
> of mismatches and read repairs ... so that would be the tricky part. I 
> believe that we just need to do what was done during the 3.0 storage 
> engine refactor (I can't remember the ticket but I'm pretty sure 
> Sylvain did the work) which checked the messaging version of the 
> destination node and sent the appropriate hash back.
>
> -Joey
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-13291
> [2] https://issues.apache.org/jira/browse/CASSANDRA-13292
> [3] https://issues.apache.org/jira/browse/CASSANDRA-14611
>
>
> On Wed, Sep 26, 2018 at 5:00 PM Elliott Sims 
> wrote:
>
> > They also don't matter for digests, as long as we're assuming all 
> > nodes
> in
> > the cluster are non-malicious (which is a pretty reasonable and 
> > probably necessary assumption).  Or at least, deliberate collisions don't.
> > Accidental collisions do, but 128 bits is sufficient to make that 
> > sufficiently unlikely (as in, chances are nobody will ever see a 
> > single
> > collision)
> >
> > On Wed, Sep 26, 2018 at 7:58 PM Brandon Williams 
> wrote:
> >
> > > Collisions don't matter in the partitioner.
> > >
> > > On Wed, Sep 26, 2018, 6:53 PM Anirudh Kubatoor <
> > anirudh.kubat...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Isn't MD5 broken from a security standpoint? From wikipedia 
> > > > *"One basic requirement of any cryptographic hash function is 
> > > > that it should be computationally infeasible <
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Computational_complexity_theory#Intractability
> > > > >
> > > > to
> > > > find two non-identical messages which hash to the same value. MD5
> fails
> > > > this requirement catastrophically; such collisions
> > > >  can be found in
> > > > seconds on an ordinary home computer"*
> > > >
> > > > Regards,
> > > > Anirudh
> > > >
> > > > On Wed, Sep 26, 2018 at 7:14 PM Jeff Jirsa  wrote:
> > > >
> > > > > In some installations, it's used for hashing the partition key to
> > find
> > > > the
> > > > > host ( RandomPartitioner )
> > > > > It's used for prepared statement IDs
> > > > > It's used for hashing the data for reads to know if the data
> matches
> > on
> > > > all
> > > > > different replicas.
> > > > >
> > > > > We don't use CRC because conflicts would be really bad. There's
> > > probably
> > > > > something in the middle that's slightly faster than md5 without the
> > > > > drawbacks of crc32
> > > > >
> > > > >
> > > > > On Wed, Sep 26, 2018 at 3:47 PM Tyagi, Preetika <
> > > > preetika.ty...@intel.com>
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I have a question about MD5 being used in the read path in
> > Cassandra.
> > > > > > I wanted to understand what exactly it is being used for and why
> > 

Re: MD5 in the read path

[Elliott Sims]

Would xxHash be large enough for digests?  Looks like there's no 128-bit
version yet, and it seems like 64 bits would be a bit short to avoid
accidental collisions/matches.  FarmHash128 or MetroHash128 might be a good
choice.  Not quite as fast as xxHash64, but not far off and still much,
much faster than MD5 and somewhat faster than murmur3. May require some
amount of benchmarking, since most of the performance comparisons are C and
the performance of the Java implementations may vary drastically.

Looks like https://issues.apache.org/jira/browse/CASSANDRA-13291 already
switched to Guava, which probably makes Murmur3_128 easier to switch to
than the rest, and it may be enough faster than MD5 to be beyond the point
of diminishing returns anyways.

 (far from an expert, but this thread prompted me to go poking through hash
options out of curiosity)

On Wed, Sep 26, 2018 at 9:04 PM Joseph Lynch  wrote:

> Michael Kjellman and others (Jason, Sam, et al.) have already done a lot of
> work in 4.0 to help change the use of MD5 to something more modern [1][2].
> Also I cut a ticket a little while back about the significant performance
> penalty of using MD5 for digests when doing quorum reads of wide partitions
> [1]. Given the profiling that Michael has done and the production profiling
> we did I think it's fair to say that changing the digest from MD5 to
> murmur3 or xxHash would lead to a noticeable performance improvement for
> quorum reads, perhaps even something like a 2x throughput increase for e.g.
> wide partition workloads.
>
> The hard part is changing the digest hash without breaking older versions,
> e.g. during a rolling restart you can't have one node give a MD5 hash and
> the other give a xxHash hash as you'll end up with lots of mismatches and
> read repairs ... so that would be the tricky part. I believe that we just
> need to do what was done during the 3.0 storage engine refactor (I can't
> remember the ticket but I'm pretty sure Sylvain did the work) which checked
> the messaging version of the destination node and sent the appropriate hash
> back.
>
> -Joey
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-13291
> [2] https://issues.apache.org/jira/browse/CASSANDRA-13292
> [3] https://issues.apache.org/jira/browse/CASSANDRA-14611
>
>
> On Wed, Sep 26, 2018 at 5:00 PM Elliott Sims 
> wrote:
>
> > They also don't matter for digests, as long as we're assuming all nodes
> in
> > the cluster are non-malicious (which is a pretty reasonable and probably
> > necessary assumption).  Or at least, deliberate collisions don't.
> > Accidental collisions do, but 128 bits is sufficient to make that
> > sufficiently unlikely (as in, chances are nobody will ever see a single
> > collision)
> >
> > On Wed, Sep 26, 2018 at 7:58 PM Brandon Williams 
> wrote:
> >
> > > Collisions don't matter in the partitioner.
> > >
> > > On Wed, Sep 26, 2018, 6:53 PM Anirudh Kubatoor <
> > anirudh.kubat...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Isn't MD5 broken from a security standpoint? From wikipedia
> > > > *"One basic requirement of any cryptographic hash function is that it
> > > > should be computationally infeasible
> > > > <
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Computational_complexity_theory#Intractability
> > > > >
> > > > to
> > > > find two non-identical messages which hash to the same value. MD5
> fails
> > > > this requirement catastrophically; such collisions
> > > >  can be found in
> > > > seconds on an ordinary home computer"*
> > > >
> > > > Regards,
> > > > Anirudh
> > > >
> > > > On Wed, Sep 26, 2018 at 7:14 PM Jeff Jirsa  wrote:
> > > >
> > > > > In some installations, it's used for hashing the partition key to
> > find
> > > > the
> > > > > host ( RandomPartitioner )
> > > > > It's used for prepared statement IDs
> > > > > It's used for hashing the data for reads to know if the data
> matches
> > on
> > > > all
> > > > > different replicas.
> > > > >
> > > > > We don't use CRC because conflicts would be really bad. There's
> > > probably
> > > > > something in the middle that's slightly faster than md5 without the
> > > > > drawbacks of crc32
> > > > >
> > > > >
> > > > > On Wed, Sep 26, 2018 at 3:47 PM Tyagi, Preetika <
> > > > preetika.ty...@intel.com>
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I have a question about MD5 being used in the read path in
> > Cassandra.
> > > > > > I wanted to understand what exactly it is being used for and why
> > not
> > > > > > something like CRC is used which is less complex in comparison to
> > > MD5.
> > > > > >
> > > > > > Thanks,
> > > > > > Preetika
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: MD5 in the read path

[Joseph Lynch]

Michael Kjellman and others (Jason, Sam, et al.) have already done a lot of
work in 4.0 to help change the use of MD5 to something more modern [1][2].
Also I cut a ticket a little while back about the significant performance
penalty of using MD5 for digests when doing quorum reads of wide partitions
[1]. Given the profiling that Michael has done and the production profiling
we did I think it's fair to say that changing the digest from MD5 to
murmur3 or xxHash would lead to a noticeable performance improvement for
quorum reads, perhaps even something like a 2x throughput increase for e.g.
wide partition workloads.

The hard part is changing the digest hash without breaking older versions,
e.g. during a rolling restart you can't have one node give a MD5 hash and
the other give a xxHash hash as you'll end up with lots of mismatches and
read repairs ... so that would be the tricky part. I believe that we just
need to do what was done during the 3.0 storage engine refactor (I can't
remember the ticket but I'm pretty sure Sylvain did the work) which checked
the messaging version of the destination node and sent the appropriate hash
back.

-Joey

[1] https://issues.apache.org/jira/browse/CASSANDRA-13291
[2] https://issues.apache.org/jira/browse/CASSANDRA-13292
[3] https://issues.apache.org/jira/browse/CASSANDRA-14611


On Wed, Sep 26, 2018 at 5:00 PM Elliott Sims  wrote:

> They also don't matter for digests, as long as we're assuming all nodes in
> the cluster are non-malicious (which is a pretty reasonable and probably
> necessary assumption).  Or at least, deliberate collisions don't.
> Accidental collisions do, but 128 bits is sufficient to make that
> sufficiently unlikely (as in, chances are nobody will ever see a single
> collision)
>
> On Wed, Sep 26, 2018 at 7:58 PM Brandon Williams  wrote:
>
> > Collisions don't matter in the partitioner.
> >
> > On Wed, Sep 26, 2018, 6:53 PM Anirudh Kubatoor <
> anirudh.kubat...@gmail.com
> > >
> > wrote:
> >
> > > Isn't MD5 broken from a security standpoint? From wikipedia
> > > *"One basic requirement of any cryptographic hash function is that it
> > > should be computationally infeasible
> > > <
> > >
> >
> https://en.wikipedia.org/wiki/Computational_complexity_theory#Intractability
> > > >
> > > to
> > > find two non-identical messages which hash to the same value. MD5 fails
> > > this requirement catastrophically; such collisions
> > >  can be found in
> > > seconds on an ordinary home computer"*
> > >
> > > Regards,
> > > Anirudh
> > >
> > > On Wed, Sep 26, 2018 at 7:14 PM Jeff Jirsa  wrote:
> > >
> > > > In some installations, it's used for hashing the partition key to
> find
> > > the
> > > > host ( RandomPartitioner )
> > > > It's used for prepared statement IDs
> > > > It's used for hashing the data for reads to know if the data matches
> on
> > > all
> > > > different replicas.
> > > >
> > > > We don't use CRC because conflicts would be really bad. There's
> > probably
> > > > something in the middle that's slightly faster than md5 without the
> > > > drawbacks of crc32
> > > >
> > > >
> > > > On Wed, Sep 26, 2018 at 3:47 PM Tyagi, Preetika <
> > > preetika.ty...@intel.com>
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I have a question about MD5 being used in the read path in
> Cassandra.
> > > > > I wanted to understand what exactly it is being used for and why
> not
> > > > > something like CRC is used which is less complex in comparison to
> > MD5.
> > > > >
> > > > > Thanks,
> > > > > Preetika
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: MD5 in the read path

[Elliott Sims]

They also don't matter for digests, as long as we're assuming all nodes in
the cluster are non-malicious (which is a pretty reasonable and probably
necessary assumption).  Or at least, deliberate collisions don't.
Accidental collisions do, but 128 bits is sufficient to make that
sufficiently unlikely (as in, chances are nobody will ever see a single
collision)

On Wed, Sep 26, 2018 at 7:58 PM Brandon Williams  wrote:

> Collisions don't matter in the partitioner.
>
> On Wed, Sep 26, 2018, 6:53 PM Anirudh Kubatoor  >
> wrote:
>
> > Isn't MD5 broken from a security standpoint? From wikipedia
> > *"One basic requirement of any cryptographic hash function is that it
> > should be computationally infeasible
> > <
> >
> https://en.wikipedia.org/wiki/Computational_complexity_theory#Intractability
> > >
> > to
> > find two non-identical messages which hash to the same value. MD5 fails
> > this requirement catastrophically; such collisions
> >  can be found in
> > seconds on an ordinary home computer"*
> >
> > Regards,
> > Anirudh
> >
> > On Wed, Sep 26, 2018 at 7:14 PM Jeff Jirsa  wrote:
> >
> > > In some installations, it's used for hashing the partition key to find
> > the
> > > host ( RandomPartitioner )
> > > It's used for prepared statement IDs
> > > It's used for hashing the data for reads to know if the data matches on
> > all
> > > different replicas.
> > >
> > > We don't use CRC because conflicts would be really bad. There's
> probably
> > > something in the middle that's slightly faster than md5 without the
> > > drawbacks of crc32
> > >
> > >
> > > On Wed, Sep 26, 2018 at 3:47 PM Tyagi, Preetika <
> > preetika.ty...@intel.com>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have a question about MD5 being used in the read path in Cassandra.
> > > > I wanted to understand what exactly it is being used for and why not
> > > > something like CRC is used which is less complex in comparison to
> MD5.
> > > >
> > > > Thanks,
> > > > Preetika
> > > >
> > > >
> > >
> >
>

Re: MD5 in the read path

[Brandon Williams]

Collisions don't matter in the partitioner.

On Wed, Sep 26, 2018, 6:53 PM Anirudh Kubatoor 
wrote:

> Isn't MD5 broken from a security standpoint? From wikipedia
> *"One basic requirement of any cryptographic hash function is that it
> should be computationally infeasible
> <
> https://en.wikipedia.org/wiki/Computational_complexity_theory#Intractability
> >
> to
> find two non-identical messages which hash to the same value. MD5 fails
> this requirement catastrophically; such collisions
>  can be found in
> seconds on an ordinary home computer"*
>
> Regards,
> Anirudh
>
> On Wed, Sep 26, 2018 at 7:14 PM Jeff Jirsa  wrote:
>
> > In some installations, it's used for hashing the partition key to find
> the
> > host ( RandomPartitioner )
> > It's used for prepared statement IDs
> > It's used for hashing the data for reads to know if the data matches on
> all
> > different replicas.
> >
> > We don't use CRC because conflicts would be really bad. There's probably
> > something in the middle that's slightly faster than md5 without the
> > drawbacks of crc32
> >
> >
> > On Wed, Sep 26, 2018 at 3:47 PM Tyagi, Preetika <
> preetika.ty...@intel.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I have a question about MD5 being used in the read path in Cassandra.
> > > I wanted to understand what exactly it is being used for and why not
> > > something like CRC is used which is less complex in comparison to MD5.
> > >
> > > Thanks,
> > > Preetika
> > >
> > >
> >
>

Re: MD5 in the read path

[Anirudh Kubatoor]

Isn't MD5 broken from a security standpoint? From wikipedia
*"One basic requirement of any cryptographic hash function is that it
should be computationally infeasible

to
find two non-identical messages which hash to the same value. MD5 fails
this requirement catastrophically; such collisions
 can be found in
seconds on an ordinary home computer"*

Regards,
Anirudh

On Wed, Sep 26, 2018 at 7:14 PM Jeff Jirsa  wrote:

> In some installations, it's used for hashing the partition key to find the
> host ( RandomPartitioner )
> It's used for prepared statement IDs
> It's used for hashing the data for reads to know if the data matches on all
> different replicas.
>
> We don't use CRC because conflicts would be really bad. There's probably
> something in the middle that's slightly faster than md5 without the
> drawbacks of crc32
>
>
> On Wed, Sep 26, 2018 at 3:47 PM Tyagi, Preetika 
> wrote:
>
> > Hi all,
> >
> > I have a question about MD5 being used in the read path in Cassandra.
> > I wanted to understand what exactly it is being used for and why not
> > something like CRC is used which is less complex in comparison to MD5.
> >
> > Thanks,
> > Preetika
> >
> >
>

Re: MD5 in the read path

[Jeff Jirsa]

In some installations, it's used for hashing the partition key to find the
host ( RandomPartitioner )
It's used for prepared statement IDs
It's used for hashing the data for reads to know if the data matches on all
different replicas.

We don't use CRC because conflicts would be really bad. There's probably
something in the middle that's slightly faster than md5 without the
drawbacks of crc32


On Wed, Sep 26, 2018 at 3:47 PM Tyagi, Preetika 
wrote:

> Hi all,
>
> I have a question about MD5 being used in the read path in Cassandra.
> I wanted to understand what exactly it is being used for and why not
> something like CRC is used which is less complex in comparison to MD5.
>
> Thanks,
> Preetika
>
>

Re: MD5 in the read path

[Elliott Sims]

Thanks to open source, you can answer yourself:
https://github.com/apache/cassandra/search?q=md5_q=md5
At a glance, looks like it's used for digest verification, and to get a
good hash distribution on the RandomPartitioner

I haven't done the math, but I suspect CRC32's just not good enough either
in terms of result distribution for hashes or ability to catch multi-bit
errors without accidental collision (that is, it doesn't sufficiently
guarantee uniqueness).  There are other error checking algorithms that are
probably less computationally complex, but thanks to a lot of hardware and
software optimizations geared towards md5 specifically over the years you'd
be hard-pressed to find something that gives you comparable speed in
practice for a 128-bit result.

MD5 in the read path

[Tyagi, Preetika]

Hi all,

I have a question about MD5 being used in the read path in Cassandra.
I wanted to understand what exactly it is being used for and why not something 
like CRC is used which is less complex in comparison to MD5.

Thanks,
Preetika

Re: QA signup

[Jay Zhuang]

+1 for publishing official snapshot artifacts for 4.0 and even other
branches.

We're publishing snapshot artifacts to our internal artifactory. One minor
bug we found is: currently build.xml won't publish any snapshot artifact:
https://issues.apache.org/jira/browse/CASSANDRA-12704

On Thu, Sep 20, 2018 at 11:35 PM Dinesh Joshi
 wrote:

> I favor versioned nightlies for testing so everyone is using the exact
> binary distribution.
>
> As far as actually building the packages go, I would prefer a Docker based
> solution like Jon mentioned. It provides a controlled, reproducible, clean
> room environment. Ideally the build script should ensure that the git
> branch is clean and that there aren't any local changes if the packages are
> being published to maven.
>
> Does anyone see a need to publish the git branch metadata in the build
> like the git-sha, branch and repo url? I am not sure if this is already
> captured somewhere. Its useful to trace a build's provenance.
>
> Dinesh
>
> > On Sep 20, 2018, at 2:26 PM, Jonathan Haddad  wrote:
> >
> > Sure - I'm not disagreeing with you that pre-built packages would be nice
> > to have.  That said, if someone's gone through the trouble of building an
> > entire testing infrastructure and has hundreds of machines available,
> > running `docker-compose up build-deb` is likely not a major issue.  If
> I'm
> > trying to decide between solving the 2 problems I'd prefer to make builds
> > easier as very few people actually know how to do it.  I'm also biased
> > because I'm working on a tool that does _exactly_ that (build arbitrary
> C*
> > debs and deploy them to AWS for perf testing with tlp-stress which we've
> > already open sourced https://github.com/thelastpickle/tlp-stress).
> >
> > I'll building it for internal TLP use but there's not much TLP specific
> > stuff, we'll be open sourcing it as soon as we can.
> >
> > TL;DR: we need both things
> >
> > On Thu, Sep 20, 2018 at 2:12 PM Scott Andreas 
> wrote:
> >
> >> Mick – Got it, thanks and sorry to have misunderstood. No fault in your
> >> writing at all; that was my misreading.
> >>
> >> Agreed with you and Kurt; I can’t think of a pressing need or immediate
> >> use for the Maven artifacts. As you mentioned, all of the examples I’d
> >> listed require binary artifacts only.
> >>
> >> Re: Jon’s question:
> >>> It seems to me that improving / simplifying the process of building the
> >> packages might solve this problem better.
> >>
> >> Agreed that making builds easy is important, and that manually-applied
> >> patches were involved in a couple cases I’d cited. My main motivation is
> >> toward making it easier for developers who’d like to produce
> >> fully-automated test pipelines to do so using common artifacts, rather
> than
> >> each replicating the build/packaging step for tarball artifacts
> themselves.
> >>
> >> Publishing binary artifacts in a common location would enable developers
> >> to configure testing and benchmarking pipelines to pick up those
> artifacts
> >> on a daily basis without intervention. In the case of a build landing
> DOA
> >> due to an issue with a commit, it’d be enough for zero-touch automation
> to
> >> pick up a new build with the fix the following day and run an extended
> >> suite across a large number of machines and publish results, for
> example.
> >>
> >>
> >> On September 19, 2018 at 8:17:05 PM, kurt greaves (k...@instaclustr.com
> >> ) wrote:
> >>
> >> It's pretty much only third party plugins. I need it for the LDAP
> >> authenticator, and StratIO's lucene plugin will also need it. I know
> there
> >> are users out there with their own custom plugins that would benefit
> from
> >> it as well (and various other open source projects). It would make it
> >> easier, however it certainly is feasible for these devs to just build
> the
> >> jars themselves (and I've done this so far). If it's going to be easy I
> >> think there's value in generating and hosting nightly jars, but if it's
> >> difficult I can just write some docs for DIY.
> >>
> >> On Thu, 20 Sep 2018 at 12:20, Mick Semb Wever  wrote:
> >>
> >>> Sorry about the terrible english in my last email.
> >>>
> >>>
>  On the target audience:
> 
>  [snip]
>  For developers building automation around testing and
>  validation, it’d be great to have a common build to work from rather
>  than each developer producing these builds themselves.
> >>>
> >>>
> >>> Sure. My question was only in context of maven artefacts.
> >>> It seems to me all the use-cases you highlight would be for the binary
> >>> artefacts.
> >>>
> >>> If that's the case we don't need to worry about publishing snapshots
> >> maven
> >>> artefacts, and can just focus on uploading nightly builds to
> >>> https://dist.apache.org/repos/dist/dev/cassandra/
> >>>
> >>> Or is there a use-case I'm missing that needs the maven artefacts?
> >>>
> >>>