EOL 2.1 series?
It came to my attention on IRC a week or so ago, and following up on the ticket that someone asked if they should commit to 2.1, that developers have been actively ignoring the 2.1 branch. If we're not committing critical fixes there, even when we know they exist, I think it's time to just call it EOL an do one last release of the few fixes that did get committed. Comments? Michael - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] releasing next 3.0 & 3.11
No problem, thanks for asking :) Michael On 1/7/19 6:20 PM, Jonathan Haddad wrote: > It's been 5 months and 30+ bug fixes to each branch. > > Here's the two changelogs: > > https://github.com/apache/cassandra/blob/cassandra-3.0/CHANGES.txt > https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt > > How's everyone feel about getting a release out this week / early next > week? Some of these bugs are show stoppers, causing OOMs and data loss. > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Who should be in our distribution KEYS file?
Yeah, I asked if someone made a request thinking I totally missed it! Since the last couple tick-tock releases, which were time based, every release has been initiated by someone commenting in IRC or dev@ that "there are a lot of things in CHANGES.txt" or "important fix foo has been committed, let's release". It looks like the interval on releases has been about 4-6 months, so we're due :) More packaging / GPG key tickets, if someone wants to take them on: https://issues.apache.org/jira/browse/CASSANDRA-14966 https://issues.apache.org/jira/browse/CASSANDRA-14967 https://issues.apache.org/jira/browse/CASSANDRA-14968 I see other Debian and RPM type repositories configured in the Apache bintray project, so perhaps signing of the package repositories can be done using their signing feature(?). I just really wish to cause users installation/upgrade difficulty as little as possible. If we're going to change up to something that allows more people to do maven and tarball releases, great, I don't care, since there's no tar-install-client that cares. I absolutely don't want deb/rpm package repository users to constantly need to update GPG keys every release, that's not nice to our users. If there is a way to get the repos set up correctly in bintray, and it's OK with INFRA to use the bintray key signing feature, great. We should set up a new package signing key and configure bintray to sign the metadata. One change for a long-term solution. Michael On 1/7/19 4:34 PM, Jeff Jirsa wrote: > I dont think it's awkward, I think a lot of us know there are serious bugs > and we need a release, but we keep finding other bugs and it's super > tempting to say "one more fix" > > We should probably just cut next 3.0.x and 3.11.x though, because there are > some nasty bugs hiding in there that the testing for 4.0 has uncovered. > > > On Mon, Jan 7, 2019 at 2:14 PM Jonathan Haddad wrote: > >>> I don't understand how adding keys changes release frequency. Did >> someone request a release to be made or are we on some assumed date >> interval? >> >> I don't know if it would (especially by itself), I just know that if more >> people are able to do releases that's more opportunity to do so. >> >> I think getting more folks involved in the release process is a good idea >> for other reasons. People take vacations, there's job conflicts, there's >> life stuff (kids usually take priority), etc. >> >> The last release of 3.11 was almost half a year ago, and there's 30+ bug >> fixes in the 3.11 branch. >> >>> Did someone request a release to be made or are we on some assumed date >> interval? >> >> I can't recall (and a search didn't find) anyone asking for a 3.11.4 >> release, but I think part of the point is that requesting a release from a >> static release manager is a sign of a flaw in the release process. >> >> On a human, note, it feels a little awkward asking for a release. I might >> be alone on this though. >> >> Jon >> >> >> On Mon, Jan 7, 2019 at 1:16 PM Michael Shuler >> wrote: >> >>> Mick and I have discussed this previously, but I don't recall if it was >>> email or irc. Apologies if I was unable to describe the problem to a >>> point of general understanding. >>> >>> To reiterate the problem, changing gpg signature keys screws our debian >>> and redhat package repositories for all users. Tarballs are not >>> installed with a client that checks signatures in a known trust >>> database. When gpg key signer changes, users need to modify their trust >>> on every node, importing new key(s), in order for packages to >>> install/upgrade with apt or yum. >>> >>> I don't understand how adding keys changes release frequency. Did >>> someone request a release to be made or are we on some assumed date >>> interval? >>> >>> Michael >>> >>> On 1/7/19 2:30 PM, Jonathan Haddad wrote: That's a good point. Looking at the ASF docs I had assumed the release manager was per-project, but on closer inspection it appears to be per-release. You're right, it does say that it can be any committer. http://www.apache.org/dev/release-publishing.html#release_manager We definitely need more frequent releases, if this is the first step towards that goal, I think it's worth it. Glad you brought this up! Jon On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever >> wrote: > > >> I don't see any reason to have any keys in there, except from release >> managers who are signing releases. > > > Shouldn't any PMC (or committer) should be able to be a release >> manager? > > The release process should be reliable and reproducible enough to be >>> safe > for rotating release managers every release. I would have thought >>> security > concerns were better addressed by a more tested process? And AFAIK no >>> other > asf projects are as restrictive on who can be the release manager role >>> (but > i've only checked a few projects).
[DISCUSS] releasing next 3.0 & 3.11
It's been 5 months and 30+ bug fixes to each branch. Here's the two changelogs: https://github.com/apache/cassandra/blob/cassandra-3.0/CHANGES.txt https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt How's everyone feel about getting a release out this week / early next week? Some of these bugs are show stoppers, causing OOMs and data loss. -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
Re: Who should be in our distribution KEYS file?
I dont think it's awkward, I think a lot of us know there are serious bugs and we need a release, but we keep finding other bugs and it's super tempting to say "one more fix" We should probably just cut next 3.0.x and 3.11.x though, because there are some nasty bugs hiding in there that the testing for 4.0 has uncovered. On Mon, Jan 7, 2019 at 2:14 PM Jonathan Haddad wrote: > > I don't understand how adding keys changes release frequency. Did > someone request a release to be made or are we on some assumed date > interval? > > I don't know if it would (especially by itself), I just know that if more > people are able to do releases that's more opportunity to do so. > > I think getting more folks involved in the release process is a good idea > for other reasons. People take vacations, there's job conflicts, there's > life stuff (kids usually take priority), etc. > > The last release of 3.11 was almost half a year ago, and there's 30+ bug > fixes in the 3.11 branch. > > > Did someone request a release to be made or are we on some assumed date > interval? > > I can't recall (and a search didn't find) anyone asking for a 3.11.4 > release, but I think part of the point is that requesting a release from a > static release manager is a sign of a flaw in the release process. > > On a human, note, it feels a little awkward asking for a release. I might > be alone on this though. > > Jon > > > On Mon, Jan 7, 2019 at 1:16 PM Michael Shuler > wrote: > > > Mick and I have discussed this previously, but I don't recall if it was > > email or irc. Apologies if I was unable to describe the problem to a > > point of general understanding. > > > > To reiterate the problem, changing gpg signature keys screws our debian > > and redhat package repositories for all users. Tarballs are not > > installed with a client that checks signatures in a known trust > > database. When gpg key signer changes, users need to modify their trust > > on every node, importing new key(s), in order for packages to > > install/upgrade with apt or yum. > > > > I don't understand how adding keys changes release frequency. Did > > someone request a release to be made or are we on some assumed date > > interval? > > > > Michael > > > > On 1/7/19 2:30 PM, Jonathan Haddad wrote: > > > That's a good point. Looking at the ASF docs I had assumed the release > > > manager was per-project, but on closer inspection it appears to be > > > per-release. You're right, it does say that it can be any committer. > > > > > > http://www.apache.org/dev/release-publishing.html#release_manager > > > > > > We definitely need more frequent releases, if this is the first step > > > towards that goal, I think it's worth it. > > > > > > Glad you brought this up! > > > Jon > > > > > > > > > On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever > wrote: > > > > > >> > > >> > > >>> I don't see any reason to have any keys in there, except from release > > >>> managers who are signing releases. > > >> > > >> > > >> Shouldn't any PMC (or committer) should be able to be a release > manager? > > >> > > >> The release process should be reliable and reproducible enough to be > > safe > > >> for rotating release managers every release. I would have thought > > security > > >> concerns were better addressed by a more tested process? And AFAIK no > > other > > >> asf projects are as restrictive on who can be the release manager role > > (but > > >> i've only checked a few projects). > > >> > > >> > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > > >> > > >> > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > -- > Jon Haddad > http://www.rustyrazorblade.com > twitter: rustyrazorblade >
Re: Who should be in our distribution KEYS file?
> I don't understand how adding keys changes release frequency. Did someone request a release to be made or are we on some assumed date interval? I don't know if it would (especially by itself), I just know that if more people are able to do releases that's more opportunity to do so. I think getting more folks involved in the release process is a good idea for other reasons. People take vacations, there's job conflicts, there's life stuff (kids usually take priority), etc. The last release of 3.11 was almost half a year ago, and there's 30+ bug fixes in the 3.11 branch. > Did someone request a release to be made or are we on some assumed date interval? I can't recall (and a search didn't find) anyone asking for a 3.11.4 release, but I think part of the point is that requesting a release from a static release manager is a sign of a flaw in the release process. On a human, note, it feels a little awkward asking for a release. I might be alone on this though. Jon On Mon, Jan 7, 2019 at 1:16 PM Michael Shuler wrote: > Mick and I have discussed this previously, but I don't recall if it was > email or irc. Apologies if I was unable to describe the problem to a > point of general understanding. > > To reiterate the problem, changing gpg signature keys screws our debian > and redhat package repositories for all users. Tarballs are not > installed with a client that checks signatures in a known trust > database. When gpg key signer changes, users need to modify their trust > on every node, importing new key(s), in order for packages to > install/upgrade with apt or yum. > > I don't understand how adding keys changes release frequency. Did > someone request a release to be made or are we on some assumed date > interval? > > Michael > > On 1/7/19 2:30 PM, Jonathan Haddad wrote: > > That's a good point. Looking at the ASF docs I had assumed the release > > manager was per-project, but on closer inspection it appears to be > > per-release. You're right, it does say that it can be any committer. > > > > http://www.apache.org/dev/release-publishing.html#release_manager > > > > We definitely need more frequent releases, if this is the first step > > towards that goal, I think it's worth it. > > > > Glad you brought this up! > > Jon > > > > > > On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever wrote: > > > >> > >> > >>> I don't see any reason to have any keys in there, except from release > >>> managers who are signing releases. > >> > >> > >> Shouldn't any PMC (or committer) should be able to be a release manager? > >> > >> The release process should be reliable and reproducible enough to be > safe > >> for rotating release managers every release. I would have thought > security > >> concerns were better addressed by a more tested process? And AFAIK no > other > >> asf projects are as restrictive on who can be the release manager role > (but > >> i've only checked a few projects). > >> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
Re: Who should be in our distribution KEYS file?
Also, in case someone brings it up, there's an ongoing relevant discussion on the builds@a.o list on automating releases, which includes lots of good thoughts on the topic. https://lists.apache.org/thread.html/af4b2a5d73fde5ab76a376549f645404da7865a8b002145435b2359c@%3Cbuilds.apache.org%3E Michael On 1/7/19 3:32 PM, Michael Shuler wrote: > To-do items that might further the goal of getting more people involved > in releases, here are a couple tickets on this: > > https://issues.apache.org/jira/browse/CASSANDRA-14962 > https://issues.apache.org/jira/browse/CASSANDRA-14963 > > #14962 is really a "we're doing it wrong" ticket on release artifacts. > There are also some comments in the details of > http://cassandra.apache.org/doc/latest/development/release_process.html > that could be streamlined and include fixing the steps, temporary upload > problems, etc. Work on temporary uploads for staging the artifacts could > be useful for #14963. > > Michael > > On 1/7/19 3:15 PM, Michael Shuler wrote: >> Mick and I have discussed this previously, but I don't recall if it was >> email or irc. Apologies if I was unable to describe the problem to a >> point of general understanding. >> >> To reiterate the problem, changing gpg signature keys screws our debian >> and redhat package repositories for all users. Tarballs are not >> installed with a client that checks signatures in a known trust >> database. When gpg key signer changes, users need to modify their trust >> on every node, importing new key(s), in order for packages to >> install/upgrade with apt or yum. >> >> I don't understand how adding keys changes release frequency. Did >> someone request a release to be made or are we on some assumed date >> interval? >> >> Michael >> >> On 1/7/19 2:30 PM, Jonathan Haddad wrote: >>> That's a good point. Looking at the ASF docs I had assumed the release >>> manager was per-project, but on closer inspection it appears to be >>> per-release. You're right, it does say that it can be any committer. >>> >>> http://www.apache.org/dev/release-publishing.html#release_manager >>> >>> We definitely need more frequent releases, if this is the first step >>> towards that goal, I think it's worth it. >>> >>> Glad you brought this up! >>> Jon >>> >>> >>> On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever wrote: >>> > I don't see any reason to have any keys in there, except from release > managers who are signing releases. Shouldn't any PMC (or committer) should be able to be a release manager? The release process should be reliable and reproducible enough to be safe for rotating release managers every release. I would have thought security concerns were better addressed by a more tested process? And AFAIK no other asf projects are as restrictive on who can be the release manager role (but i've only checked a few projects). - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >> > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Who should be in our distribution KEYS file?
To-do items that might further the goal of getting more people involved in releases, here are a couple tickets on this: https://issues.apache.org/jira/browse/CASSANDRA-14962 https://issues.apache.org/jira/browse/CASSANDRA-14963 #14962 is really a "we're doing it wrong" ticket on release artifacts. There are also some comments in the details of http://cassandra.apache.org/doc/latest/development/release_process.html that could be streamlined and include fixing the steps, temporary upload problems, etc. Work on temporary uploads for staging the artifacts could be useful for #14963. Michael On 1/7/19 3:15 PM, Michael Shuler wrote: > Mick and I have discussed this previously, but I don't recall if it was > email or irc. Apologies if I was unable to describe the problem to a > point of general understanding. > > To reiterate the problem, changing gpg signature keys screws our debian > and redhat package repositories for all users. Tarballs are not > installed with a client that checks signatures in a known trust > database. When gpg key signer changes, users need to modify their trust > on every node, importing new key(s), in order for packages to > install/upgrade with apt or yum. > > I don't understand how adding keys changes release frequency. Did > someone request a release to be made or are we on some assumed date > interval? > > Michael > > On 1/7/19 2:30 PM, Jonathan Haddad wrote: >> That's a good point. Looking at the ASF docs I had assumed the release >> manager was per-project, but on closer inspection it appears to be >> per-release. You're right, it does say that it can be any committer. >> >> http://www.apache.org/dev/release-publishing.html#release_manager >> >> We definitely need more frequent releases, if this is the first step >> towards that goal, I think it's worth it. >> >> Glad you brought this up! >> Jon >> >> >> On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever wrote: >> >>> >>> I don't see any reason to have any keys in there, except from release managers who are signing releases. >>> >>> >>> Shouldn't any PMC (or committer) should be able to be a release manager? >>> >>> The release process should be reliable and reproducible enough to be safe >>> for rotating release managers every release. I would have thought security >>> concerns were better addressed by a more tested process? And AFAIK no other >>> asf projects are as restrictive on who can be the release manager role (but >>> i've only checked a few projects). >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> >> > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Who should be in our distribution KEYS file?
Mick and I have discussed this previously, but I don't recall if it was email or irc. Apologies if I was unable to describe the problem to a point of general understanding. To reiterate the problem, changing gpg signature keys screws our debian and redhat package repositories for all users. Tarballs are not installed with a client that checks signatures in a known trust database. When gpg key signer changes, users need to modify their trust on every node, importing new key(s), in order for packages to install/upgrade with apt or yum. I don't understand how adding keys changes release frequency. Did someone request a release to be made or are we on some assumed date interval? Michael On 1/7/19 2:30 PM, Jonathan Haddad wrote: > That's a good point. Looking at the ASF docs I had assumed the release > manager was per-project, but on closer inspection it appears to be > per-release. You're right, it does say that it can be any committer. > > http://www.apache.org/dev/release-publishing.html#release_manager > > We definitely need more frequent releases, if this is the first step > towards that goal, I think it's worth it. > > Glad you brought this up! > Jon > > > On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever wrote: > >> >> >>> I don't see any reason to have any keys in there, except from release >>> managers who are signing releases. >> >> >> Shouldn't any PMC (or committer) should be able to be a release manager? >> >> The release process should be reliable and reproducible enough to be safe >> for rotating release managers every release. I would have thought security >> concerns were better addressed by a more tested process? And AFAIK no other >> asf projects are as restrictive on who can be the release manager role (but >> i've only checked a few projects). >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Who should be in our distribution KEYS file?
That's a good point. Looking at the ASF docs I had assumed the release manager was per-project, but on closer inspection it appears to be per-release. You're right, it does say that it can be any committer. http://www.apache.org/dev/release-publishing.html#release_manager We definitely need more frequent releases, if this is the first step towards that goal, I think it's worth it. Glad you brought this up! Jon On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever wrote: > > > > I don't see any reason to have any keys in there, except from release > > managers who are signing releases. > > > Shouldn't any PMC (or committer) should be able to be a release manager? > > The release process should be reliable and reproducible enough to be safe > for rotating release managers every release. I would have thought security > concerns were better addressed by a more tested process? And AFAIK no other > asf projects are as restrictive on who can be the release manager role (but > i've only checked a few projects). > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
Re: Who should be in our distribution KEYS file?
> I don't see any reason to have any keys in there, except from release > managers who are signing releases. Shouldn't any PMC (or committer) should be able to be a release manager? The release process should be reliable and reproducible enough to be safe for rotating release managers every release. I would have thought security concerns were better addressed by a more tested process? And AFAIK no other asf projects are as restrictive on who can be the release manager role (but i've only checked a few projects). - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Who should be in our distribution KEYS file?
I agree with Stefan, if someone isn't a release manager there's no reason to add them, and it just increases the surface area for potential attack or issue. On Mon, Jan 7, 2019 at 11:35 AM Stefan Podkowinski wrote: > I don't see any reason to have any keys in there, except from release > managers who are signing releases. Additional keys from other developers > may even harm security, by creating more opportunities for compromising > keys. > > On 07.01.19 11:29, Mick Semb Wever wrote: > > And when should it get updated? > > > > Currently our KEYS file: that contains the public keys of those that can > signed released binary artifacts; only contains a few of the PMC. My > understanding is that we've avoid updating it because it causes headache > for operators in having to validate the authenticity of a new key that's > signed a binary when upgrading. > > > > If this is accurate, how prevalent is this problem actually on > operators? Do some operators download the KEYS fresh from apache.org > every release? Are the keys of our PMCs already in the existing web of > trust? > > > > I'm not knowledgeable on the precedence here for operators, and curious > to what's the community's stance (and why)… And whether it is the time > right to add all/more our PMC to the file? And whether we should always add > new PMC to the file (if they're already in the web of trust?)? > > > > cheers, > > Mick > > > > https://www.apache.org/info/verification.html#Validating > > https://www.apache.org/dyn/closer.cgi#verify > > https://dist.apache.org/repos/dist/release/cassandra/KEYS > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
Re: Who should be in our distribution KEYS file?
I don't see any reason to have any keys in there, except from release managers who are signing releases. Additional keys from other developers may even harm security, by creating more opportunities for compromising keys. On 07.01.19 11:29, Mick Semb Wever wrote: And when should it get updated? Currently our KEYS file: that contains the public keys of those that can signed released binary artifacts; only contains a few of the PMC. My understanding is that we've avoid updating it because it causes headache for operators in having to validate the authenticity of a new key that's signed a binary when upgrading. If this is accurate, how prevalent is this problem actually on operators? Do some operators download the KEYS fresh from apache.org every release? Are the keys of our PMCs already in the existing web of trust? I'm not knowledgeable on the precedence here for operators, and curious to what's the community's stance (and why)… And whether it is the time right to add all/more our PMC to the file? And whether we should always add new PMC to the file (if they're already in the web of trust?)? cheers, Mick https://www.apache.org/info/verification.html#Validating https://www.apache.org/dyn/closer.cgi#verify https://dist.apache.org/repos/dist/release/cassandra/KEYS - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Cassandra website docs for 3.11 added
This is fantastic!! Thanks a bunch for the effort on this, folks. On Mon, Jan 7, 2019 at 4:31 PM Mick Semb Wever wrote: > > > > Next step it to regenerate the docs for Cassandra-4.0 (latest). I'll do > > this next week if no one objects. > > > This has been done by Joey Lynch, Anthony Grasso and myself . > See https://cassandra.apache.org/doc/latest/ > > > > a) list and link to the different versions of the docs > > A very basic initial version of this is proposed in CASSANDRA-14954 just by > disabling the redirect and enabling directory listing under > https://cassandra.apache.org/doc/ > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Who should be in our distribution KEYS file?
And when should it get updated? Currently our KEYS file: that contains the public keys of those that can signed released binary artifacts; only contains a few of the PMC. My understanding is that we've avoid updating it because it causes headache for operators in having to validate the authenticity of a new key that's signed a binary when upgrading. If this is accurate, how prevalent is this problem actually on operators? Do some operators download the KEYS fresh from apache.org every release? Are the keys of our PMCs already in the existing web of trust? I'm not knowledgeable on the precedence here for operators, and curious to what's the community's stance (and why)… And whether it is the time right to add all/more our PMC to the file? And whether we should always add new PMC to the file (if they're already in the web of trust?)? cheers, Mick https://www.apache.org/info/verification.html#Validating https://www.apache.org/dyn/closer.cgi#verify https://dist.apache.org/repos/dist/release/cassandra/KEYS - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
