Re: Who should be in our distribution KEYS file?

2019-01-09 Thread Michael Shuler
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?

2019-01-09 Thread Michael Shuler
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?

2019-01-09 Thread Stefan Podkowinski
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?

2019-01-07 Thread Michael Shuler
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?

2019-01-07 Thread Jeff Jirsa
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?

2019-01-07 Thread Jonathan Haddad
> 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?

2019-01-07 Thread Michael Shuler
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?

2019-01-07 Thread Michael Shuler
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?

2019-01-07 Thread Michael Shuler
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?

2019-01-07 Thread Jonathan Haddad
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?

2019-01-07 Thread Mick Semb Wever



> 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?

2019-01-07 Thread Jonathan Haddad
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?

2019-01-07 Thread Stefan Podkowinski
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