GSoC 2016
Sir/Ma'am, I am new to open source and have some knowledge in C/C++ and JAVA. I want to participate in GSOC '16 for ASAF. Can you please guide me through the process. I am serious about contributing to ASAF and participating in GSOC '16 and willing to learn new things that are required in the process. Your help will be much appreciated.
Re: GSoC 2016
Rajdeep Surolia wrote on 2/25/16 6:28 AM: > Sir/Ma'am, > I am new to open source and have some knowledge in C/C++ and > JAVA. I want to participate in GSOC '16 for ASAF. Can you please guide me > through the process. I am serious about contributing to ASAF and > participating in GSOC '16 and willing to learn new things that are required > in the process. Your help will be much appreciated. The GSoC application process for students doesn't start until 14 March. While mentoring organizations haven't formally been announced, we expect the ASF and a number of our Apache projects to be participating - however we don't have that list ready yet. The best thing to do now is review the GSoC site for the process: https://developers.google.com/open-source/gsoc/ If you want to start looking at what different projects are at the ASF, you can browse our projects directory - but note, only some projects will be participating in the formal GSoC program: https://projects.apache.org/ Thanks for your interest and good luck! - Shane
Re: GSOC 2016
Prashant Kumar wrote on 2/15/16 12:34 AM: > Sir/Mam, > My name is Prashant Kumar and I am 3rd year b.tech student of Netaji > Subhash Engineering College, Kolkata. > I am interested in GSOC 2016 and would like to contribute to your projects > using C, C++ languages. I love coding and have participated in competetions > like Codevita. > It would be very helpful if I could be guided on how to get started and > what kind of projects are to be started this year. > Looking forward to your reply. Thank you > The GSoC application process for students doesn't start until 14 March. While mentoring organizations haven't formally been announced, we expect the ASF and a number of our Apache projects to be participating - however we don't have that list ready yet. The best thing to do now is review the GSoC site for the process: https://developers.google.com/open-source/gsoc/ If you want to start looking at what different projects are at the ASF, you can browse our projects directory - but note, only some projects will be participating in the formal GSoC program: https://projects.apache.org/ Thanks for your interest and good luck! - Shane
Automated ASF GPG signing
I'm not sure where exactly this discussion should fit, but I know people have brought up questions about ASF-wide signing of artifacts before, so I'll just mention it on this list. Fedora infrastructure has built a project called sigul: https://fedorahosted.org/sigul/ which they use as part of their infrastructure to automate signing of RPMs and ISOs and such. ASF could set up a similar service for ASF-wide release signing. This particular project looks like it has a GPL2 license on it, and I'm not sure what the policy is for Fedora infrastructure, but for Fedora packagers, contributions (under their ICLA) are MIT, so it's possible that if we wanted to use this, and provide ASF-wide release signing, the Fedora community would be willing to re-license under MIT if that were necessary for us to consider using it.
Re: Automated ASF GPG signing
Christopher wrote on 2/25/16 1:47 PM: > I'm not sure where exactly this discussion should fit, but I know people > have brought up questions about ASF-wide signing of artifacts before, so > I'll just mention it on this list. > > Fedora infrastructure has built a project called sigul: > https://fedorahosted.org/sigul/ > which they use as part of their infrastructure to automate signing of RPMs > and ISOs and such. > > ASF could set up a similar service for ASF-wide release signing. > > This particular project looks like it has a GPL2 license on it, and I'm not > sure what the policy is for Fedora infrastructure, but for Fedora > packagers, contributions (under their ICLA) are MIT, so it's possible that > if we wanted to use this, and provide ASF-wide release signing, the Fedora > community would be willing to re-license under MIT if that were necessary > for us to consider using it. > Interesting point. The first question is: what Apache projects want to do something like this? While volunteers can work on whatever new ideas people like working on, we don't tend to build officially supported services (especially security-related ones!) unless there are some specific PMCs that ask for it. Once there's some interest from projects, it's a question of figuring out a draft plan and seeing if the security and maintenance are something the ASF and our small but awesome infrastructure team would be willing to host. Also, have you read through the Apache release policy and signing details to see exactly how this would fit? http://www.apache.org/dev/release.html http://www.apache.org/dev/release-signing.html The ASF does have a central code signing service for Windows binaries and JARs supported by Symantec, although it's not widely used yet: https://reference.apache.org/pmc/codesigning - Shane
Re: Automated ASF GPG signing
On Thu, Feb 25, 2016 at 2:10 PM Shane Curcuru wrote: > Christopher wrote on 2/25/16 1:47 PM: > > I'm not sure where exactly this discussion should fit, but I know people > > have brought up questions about ASF-wide signing of artifacts before, so > > I'll just mention it on this list. > > > > Fedora infrastructure has built a project called sigul: > > https://fedorahosted.org/sigul/ > > which they use as part of their infrastructure to automate signing of > RPMs > > and ISOs and such. > > > > ASF could set up a similar service for ASF-wide release signing. > > > > This particular project looks like it has a GPL2 license on it, and I'm > not > > sure what the policy is for Fedora infrastructure, but for Fedora > > packagers, contributions (under their ICLA) are MIT, so it's possible > that > > if we wanted to use this, and provide ASF-wide release signing, the > Fedora > > community would be willing to re-license under MIT if that were necessary > > for us to consider using it. > > > Interesting point. The first question is: what Apache projects want to > do something like this? While volunteers can work on whatever new ideas > people like working on, we don't tend to build officially supported > services (especially security-related ones!) unless there are some > specific PMCs that ask for it. > > I think the main reason why we would want to use something like this has been expounded before, but in short, the idea is that it makes it easier for downstream users to trust ASF releases, rather than being required to trust individual developers's code-signing key. This would improve user confidence in a release. On the other hand, using centralized keys would increase the impact of a key compromise if such a thing were to occur. But, at least we could mitigate and prevent key compromise a bit better than what most users are probably doing today. > Once there's some interest from projects, it's a question of figuring > out a draft plan and seeing if the security and maintenance are > something the ASF and our small but awesome infrastructure team would be > willing to host. > > Also, have you read through the Apache release policy and signing > details to see exactly how this would fit? > > http://www.apache.org/dev/release.html > http://www.apache.org/dev/release-signing.html > > I think the idea would be that if we were to do something like this, it would run as an authenticated service, and return a signature for files uploaded to it upon request. It would replace the need for individuals to generate and use their own GPG keys. The tricky part would be to establish policy and enforcement of its use for ASF-releases only. It would probably have to be used for release candidates also. It would obviously have to be locked down to release managers, but who are the authorized release managers (PMC, committers, other?), and how does one tell what is an authorized release artifact? Trust of the system might have to rely on audit logs and policy, rather than strict enforcement, which isn't idea. A related service could possibly be set up, so instead of pushing directly to the mirrors, uploading to dist would trigger signing? We'd also probably need to address uploading to the Maven Central staging repositories. For Maven projects, a maven plugin could easily be written which uses this service and replaces the maven-gpg-plugin. It could also be done on deploy, en route to the staging repositories. An alternative implementation would be that this service would escrow keys not just for ASF-wide, but also for per-project(PMC), so there could be a single trusted key per project. The ASF does have a central code signing service for Windows binaries > and JARs supported by Symantec, although it's not widely used yet: > > https://reference.apache.org/pmc/codesigning > > This would wouldn't replace those, but it would provide a similar centralized trust mechanism for GPG signatures which would be suitable to replace the existing release-signing practices. It'd probably be cheaper to provide than the Symantec service, and would perhaps limit the number of users who have an interest (but not an essential requirement) for that service.
Re: Automated ASF GPG signing
It seems reasonable to me to tack code signing onto the end of CI builds from the likes of buildbot and Jenkins. You can then restrict your code signing service to the robots and avoid the pesky problems humans introduce into the process. -- Daniel Ruggeri On 2/25/2016 1:57 PM, Christopher wrote: > The tricky part would be to establish policy and enforcement of its use for > ASF-releases only. It would probably have to be used for release candidates > also. It would obviously have to be locked down to release managers, but > who are the authorized release managers (PMC, committers, other?), and how > does one tell what is an authorized release artifact? Trust of the system > might have to rely on audit logs and policy, rather than strict > enforcement, which isn't idea. > > A related service could possibly be set up, so instead of pushing directly > to the mirrors, uploading to dist would trigger signing? We'd also probably > need to address uploading to the Maven Central staging repositories. For > Maven projects, a maven plugin could easily be written which uses this > service and replaces the maven-gpg-plugin. It could also be done on deploy, > en route to the staging repositories. > > An alternative implementation would be that this service would escrow keys > not just for ASF-wide, but also for
