Re: Encouraging More Women to Participate on Apache Projects?

[Marvin Humphrey]

On Thu, May 19, 2016 at 8:17 AM, Sharan Foga  wrote:
> Hi All
>
> I'm interested in finding out how we could encourage more women to
> participate on Apache projects. It's a discussion topic that came up last
> week while I was at Apachecon. My understanding is that we don't have any
> current strategies in place so I think it could be good to look at gathering
> some ideas about how to tackle the problem and also hear about any lessons
> learned from any previous or similar strategies.
>
> What do people think?

One thing that individual projects can do is affirm the ASF Code of
Conduct on their websites.

  http://couchdb.apache.org/#contribute
  https://www.apache.org/foundation/policies/conduct

I'd suggest that anybody who feels like scratching this itch JFDI,
using the CouchDB language as a template. Don't ask permission first
and don't sweat the wording, just update the website -- because the
Code of Conduct already applies across all Apache projects. If people
feel like iterating on the wording later, that's fine -- but get
something up there to start with.

And then, once it's up, it would be great to hear back on this list about it. :)

Marvin Humphrey

Re: SHA512 by default for GPG sigs

[Christopher]

On Thu, May 19, 2016 at 2:43 AM Stian Soiland-Reyes 
wrote:

> In principle +1, a PGP signature based on sha1 is not cryptographically
> strong.
>
> Obviously blindly checking a PGP signature, even after importing the KEYS
> from https://www.apache.org/dist, that is also not any proof you got the
> intended release, just an artifact by someone who previously signed some
> ASF release. (If you are paranoid and/or work my for a three-letter
> government institution, then you probably want more proof of exactly which
> version you are downloading)
>
>
Agreed. That's why folks also are encouraged to grow their web of trust.
Frankly, though, I'm generally content with any valid signature from a key
in a PMC's managed KEYS file, at least for the purposes of verifying
releases. That's because I have a reasonable confidence in the Apache
infrastructure to secure the published KEYS files, and that the release
managers are using their keys to act in the interest of their respective
PMCs (or at least, not using them to act against it by falsifying
unofficial releases).

A GPG signature doesn't attest that "content X came from entity E". It
attests that "the content whose hash is X came from entity E". So, that
attestation is only as strong as the hash algorithm. Weaker algorithms are
subject to "pre-image" attacks (maybe still a long way off for SHA-1, but
we still should avoid it).


> I think the convenience of the old standard .sha1 and .md5 files is that
> they can also be included in this VOTE emails, forming a distributed
> evidence in list archives of which release was approved. (although I see
> many projects now being made more lax about this and just refer to a
> transient Maven step repo). In addition to being easy to check, they are
> also easy to inline say in a Dockerfile, so I would not get rid of those
> even if the .asc is improved.
>
>
Agreed. I also wouldn't get rid of those. They have their own utility. This
is just about making the *.asc detached signature files stronger.


> Are there any compatibility issues for downstream users with your proposed
> default change? What about for Maven deployment? I assume a newer gpg is
> needed; what would be the new version requirement, and how does this match
> what is available in typical distros and OS installs?
> On 18 May 2016 7:55 p.m., "Christopher"  wrote:
>
>
It's possible, but I think very unlikely that this would cause any problems
for anybody. GnuPG added support for SHA512 in early 2003, and all the tags
in GnuPG's git repo seem to support it. Old versions of OpenPGP didn't
support it, but that's a dead project (AFAICT), and in any case, this is
the maven-gpg-plugin, not the maven-openpgp-plugin. All tags in the gnupg
git repo seem to support SHA512. Anything installed today should support
it. If there are concerning compatibility issues, then those issues would
already be a problem for the documented ASF advice at
https://www.apache.org/dev/openpgp

This doesn't affect Maven deployments at all, except to make the signatures
emitted in the release profile's activation of maven-gpg-plugin stronger.

This really should be transparent. How rare it is to get more security
without having to trade anything of value for it... but it seems to me
that's what we have in this situation.

Re: SHA512 by default for GPG sigs

[Martin Desruisseaux]

+0 on my side. Seems a good thing, but I may not master all the aspects.

Martin


Le 18/05/16 à 13:45, Christopher a écrit :
> Hi all,
>
> I'm not sure a better list to get feedback on, but I wanted to bring
> attention to the proposal here:
> https://issues.apache.org/jira/browse/MPOM-118
>
> Essentially this is a suggestion to configure the maven-gpg-plugin to sign
> using SHA512 as its digest algorithm in the ASF Parent POM, used by many
> Maven/Java-based projects within ASF. This configuration takes affect
> during software releases when this plugin is activated (typically prior to
> a release candidate vote, and staging a release in Nexus for distribution
> to Maven Central).
>
> This would only affect the hash algorithm used to generate GPG signatures
> for releases, and not any separate SHA/MD hashes published separately by
> any project, which can be weaker (SHA1, MD5) for convenience, and don't
> convey the strong authenticity statement that digital signatures provide.
>
> For background, gpg uses SHA1 by default, unless the signing key or gpg
> configuration has a preference to use another algorithm (as described on
> https://www.apache.org/dev/openpgp).
>
> This proposed configuration change wouldn't force the use of SHA512 (it
> could still be overridden by a project), but it would make it the default,
> which helps improve the security of releases in the case where release
> managers have failed to keep their configuration up-to-date with the best
> recommendations for using gpg.
>
> Thoughts? +1s? Discuss here or on the JIRA please.
>
> Thank you.

RE: Encouraging More Women to Participate on Apache Projects?

[Ross Gardler]

We do not have current strategies. We've tried many things in the past but 
they've never really succeeded. I'll not speculate on why, it's a complex issue.

What I will say (with my Presidents hat firmly on), is that if folks come up 
with a strategy that is in line with our charitable mission then please don't 
hesitate to ask for any support you need.

Ross

> -Original Message-
> From: Sharan Foga [mailto:sharan.f...@gmail.com]
> Sent: Thursday, May 19, 2016 8:18 AM
> To: dev@community.apache.org
> Subject: Encouraging More Women to Participate on Apache Projects?
> 
> Hi All
> 
> I'm interested in finding out how we could encourage more women to
> participate on Apache projects. It's a discussion topic that came up last week
> while I was at Apachecon. My understanding is that we don't have any current
> strategies in place so I think it could be good to look at gathering some 
> ideas
> about how to tackle the problem and also hear about any lessons learned from
> any previous or similar strategies.
> 
> What do people think?
> 
> Thanks
> Sharan
> 

Encouraging More Women to Participate on Apache Projects?

[Sharan Foga]

Hi All

I'm interested in finding out how we could encourage more women to 
participate on Apache projects. It's a discussion topic that came up 
last week while I was at Apachecon. My understanding is that we don't 
have any current strategies in place so I think it could be good to look 
at gathering some ideas about how to tackle the problem and also hear 
about any lessons learned from any previous or similar strategies.


What do people think?

Thanks
Sharan

Re: SHA512 by default for GPG sigs

[Sergio Fernández]

+1

On Wed, May 18, 2016 at 7:45 PM, Christopher  wrote:

> Hi all,
>
> I'm not sure a better list to get feedback on, but I wanted to bring
> attention to the proposal here:
> https://issues.apache.org/jira/browse/MPOM-118
>
> Essentially this is a suggestion to configure the maven-gpg-plugin to sign
> using SHA512 as its digest algorithm in the ASF Parent POM, used by many
> Maven/Java-based projects within ASF. This configuration takes affect
> during software releases when this plugin is activated (typically prior to
> a release candidate vote, and staging a release in Nexus for distribution
> to Maven Central).
>
> This would only affect the hash algorithm used to generate GPG signatures
> for releases, and not any separate SHA/MD hashes published separately by
> any project, which can be weaker (SHA1, MD5) for convenience, and don't
> convey the strong authenticity statement that digital signatures provide.
>
> For background, gpg uses SHA1 by default, unless the signing key or gpg
> configuration has a preference to use another algorithm (as described on
> https://www.apache.org/dev/openpgp).
>
> This proposed configuration change wouldn't force the use of SHA512 (it
> could still be overridden by a project), but it would make it the default,
> which helps improve the security of releases in the case where release
> managers have failed to keep their configuration up-to-date with the best
> recommendations for using gpg.
>
> Thoughts? +1s? Discuss here or on the JIRA please.
>
> Thank you.
>



-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co

Re: SHA512 by default for GPG sigs

[Stian Soiland-Reyes]

In principle +1, a PGP signature based on sha1 is not cryptographically
strong.

Obviously blindly checking a PGP signature, even after importing the KEYS
from https://www.apache.org/dist, that is also not any proof you got the
intended release, just an artifact by someone who previously signed some
ASF release. (If you are paranoid and/or work my for a three-letter
government institution, then you probably want more proof of exactly which
version you are downloading)

I think the convenience of the old standard .sha1 and .md5 files is that
they can also be included in this VOTE emails, forming a distributed
evidence in list archives of which release was approved. (although I see
many projects now being made more lax about this and just refer to a
transient Maven step repo). In addition to being easy to check, they are
also easy to inline say in a Dockerfile, so I would not get rid of those
even if the .asc is improved.

Are there any compatibility issues for downstream users with your proposed
default change? What about for Maven deployment? I assume a newer gpg is
needed; what would be the new version requirement, and how does this match
what is available in typical distros and OS installs?
On 18 May 2016 7:55 p.m., "Christopher"  wrote:

> Hi all,
>
> I'm not sure a better list to get feedback on, but I wanted to bring
> attention to the proposal here:
> https://issues.apache.org/jira/browse/MPOM-118
>
> Essentially this is a suggestion to configure the maven-gpg-plugin to sign
> using SHA512 as its digest algorithm in the ASF Parent POM, used by many
> Maven/Java-based projects within ASF. This configuration takes affect
> during software releases when this plugin is activated (typically prior to
> a release candidate vote, and staging a release in Nexus for distribution
> to Maven Central).
>
> This would only affect the hash algorithm used to generate GPG signatures
> for releases, and not any separate SHA/MD hashes published separately by
> any project, which can be weaker (SHA1, MD5) for convenience, and don't
> convey the strong authenticity statement that digital signatures provide.
>
> For background, gpg uses SHA1 by default, unless the signing key or gpg
> configuration has a preference to use another algorithm (as described on
> https://www.apache.org/dev/openpgp).
>
> This proposed configuration change wouldn't force the use of SHA512 (it
> could still be overridden by a project), but it would make it the default,
> which helps improve the security of releases in the case where release
> managers have failed to keep their configuration up-to-date with the best
> recommendations for using gpg.
>
> Thoughts? +1s? Discuss here or on the JIRA please.
>
> Thank you.
>

Re: slides for ApacheCon NA 2016?

[Sergio Fernández]

On Wed, May 18, 2016 at 7:05 PM, Rich Bowen  wrote:

> Session Slides:
> Session slides can be found within the schedule. To view slides, click
> here -
>
> http://events.linuxfoundation.org/events/apache-big-data-north-america/program/schedule
> - choose the session you’d like slides for and a pdf will be attached in
> the session description field if the speaker has shared them with us. If
> you don’t find the slides you are looking for, please check back as
> speakers are continually sharing them with us to post.


OK, great, thanks.


-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co