Re: Who should be in our distribution KEYS file?
Sorry, I forgot to include the most important feature for potentially using bintray deb/rpm repos, signed by the bintray key: - New gpg keys could be added to KEYS for interested new release managers, and releases could be done by those interested new Cassandra release managers, requiring only one key change for deb/rpm repository users. Michael On 1/9/19 11:13 AM, Michael Shuler wrote: > For Debian, Fedora, etc. to package Cassandra at the OS level, first all > dependencies (and deps of deps) must be packaged and uploaded, so they > can be depended on by Cassandra. This means Hadoop. It has been > attempted and abandoned by multiple people, myself included. > > A little digging on one example Apache project hosting deb/rpm repos at > bintray, Apache Ignite, there are multiple repo problems that can be > solved by the tickets I listed below. > > Details: > https://issues.apache.org/jira/browse/CASSANDRA-14968?focusedCommentId=16738342=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16738342 > > tl;dr: > - I think we can use the bintray key to sign the repos, there's precedent > - using bintray to build the deb/rpm repos, all version in each suite > (22x, 30x, ..) will be installable, instead of just the latest version > > Michael > > On 1/9/19 8:06 AM, Stefan Podkowinski wrote: >> If creating native deb/rpm package signatures and repo metadata >> signatures is the only issue that stops us from releasing more often and >> sharing the burden in doing so, then I'd be happy to discuss dropping >> this altogether. We can always distribute binary packages along with >> checksums and a detached gpg signature by any KEYS person, just as we do >> with the tarballs. >> >> Having an Apache hosted Cassandra yum/deb repo may be convenient, but I >> wonder how many users will still download the packages and host them in >> their own internal repo. Even if it's just to have the option to pin the >> package to a specific version, which we currently don't offer, as only >> the latest package is included in the repo metadata. It might also >> encourage distros to keep downstream repos updated as well, since that >> would be the ideal way of creating and distributing package, i.e. having >> a Debian/Fedora/Ubuntu maintainer taking care of that and only have >> users come back to us for the vanilla rpm in case their downstream >> version is outdated. >> >> >> On 08.01.19 02:48, Michael Shuler wrote: >>> 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
Re: Who should be in our distribution KEYS file?
For Debian, Fedora, etc. to package Cassandra at the OS level, first all dependencies (and deps of deps) must be packaged and uploaded, so they can be depended on by Cassandra. This means Hadoop. It has been attempted and abandoned by multiple people, myself included. A little digging on one example Apache project hosting deb/rpm repos at bintray, Apache Ignite, there are multiple repo problems that can be solved by the tickets I listed below. Details: https://issues.apache.org/jira/browse/CASSANDRA-14968?focusedCommentId=16738342=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16738342 tl;dr: - I think we can use the bintray key to sign the repos, there's precedent - using bintray to build the deb/rpm repos, all version in each suite (22x, 30x, ..) will be installable, instead of just the latest version Michael On 1/9/19 8:06 AM, Stefan Podkowinski wrote: > If creating native deb/rpm package signatures and repo metadata > signatures is the only issue that stops us from releasing more often and > sharing the burden in doing so, then I'd be happy to discuss dropping > this altogether. We can always distribute binary packages along with > checksums and a detached gpg signature by any KEYS person, just as we do > with the tarballs. > > Having an Apache hosted Cassandra yum/deb repo may be convenient, but I > wonder how many users will still download the packages and host them in > their own internal repo. Even if it's just to have the option to pin the > package to a specific version, which we currently don't offer, as only > the latest package is included in the repo metadata. It might also > encourage distros to keep downstream repos updated as well, since that > would be the ideal way of creating and distributing package, i.e. having > a Debian/Fedora/Ubuntu maintainer taking care of that and only have > users come back to us for the vanilla rpm in case their downstream > version is outdated. > > > On 08.01.19 02:48, Michael Shuler wrote: >> 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
Re: Who should be in our distribution KEYS file?
If creating native deb/rpm package signatures and repo metadata signatures is the only issue that stops us from releasing more often and sharing the burden in doing so, then I'd be happy to discuss dropping this altogether. We can always distribute binary packages along with checksums and a detached gpg signature by any KEYS person, just as we do with the tarballs. Having an Apache hosted Cassandra yum/deb repo may be convenient, but I wonder how many users will still download the packages and host them in their own internal repo. Even if it's just to have the option to pin the package to a specific version, which we currently don't offer, as only the latest package is included in the repo metadata. It might also encourage distros to keep downstream repos updated as well, since that would be the ideal way of creating and distributing package, i.e. having a Debian/Fedora/Ubuntu maintainer taking care of that and only have users come back to us for the vanilla rpm in case their downstream version is outdated. On 08.01.19 02:48, Michael Shuler wrote: 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.
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).
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
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
