Confirmed users
512
edits
Community:SummerOfCode16: Difference between revisions
Removing ServiceWorker project for Servo
(→Instantbird: Expand file transfer project) |
(Removing ServiceWorker project for Servo) |
||
| (17 intermediate revisions by 9 users not shown) | |||
| Line 13: | Line 13: | ||
* Read [http://blog.gerv.net/2006/05/how_not_to_apply_for_summer_of/ How Not To Apply For Summer Of Code] and avoid doing the things listed there. | * Read [http://blog.gerv.net/2006/05/how_not_to_apply_for_summer_of/ How Not To Apply For Summer Of Code] and avoid doing the things listed there. | ||
* Read our examples of good applications: [[SummerOfCode/SampleApplications/1|1]], [[SummerOfCode/SampleApplications/2|2]], [[SummerOfCode/SampleApplications/3|3]]. | * Read our examples of good applications: [[SummerOfCode/SampleApplications/1|1]], [[SummerOfCode/SampleApplications/2|2]], [[SummerOfCode/SampleApplications/3|3]]. | ||
* Apply on [ | * Apply on [https://summerofcode.withgoogle.com/ the GSoC site] (note that we have an [[SummerOfCode/ApplicationTemplate|application template]]). | ||
* It is entirely acceptable to apply for 2 or 3 projects, if more than one catches your eye; if the applications are high quality, that can improve your chances. However, more than 3 seems like spam. | * It is entirely acceptable to apply for 2 or 3 projects, if more than one catches your eye; if the applications are high quality, that can improve your chances. However, more than 3 seems like spam. | ||
| Line 32: | Line 32: | ||
|- | |- | ||
| Download app assets at runtime | | Download app assets at runtime | ||
| With Firefox for Android we just made the first steps to stop shipping everything in the APK and to instead download assets the application needs at runtime. We started with fonts but we want to do much more (hyphenation dictionaries, translations, ..) in order to reduce the APK size. | | [[Community:SummerOfCode16/AndroidDownloadableContent|More detailed description of the project]] | ||
With Firefox for Android we just made the first steps to stop shipping everything in the APK and to instead download assets the application needs at runtime. We started with fonts but we want to do much more (hyphenation dictionaries, translations, ..) in order to reduce the APK size. | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1194338 Meta bug 1194338 (Support for downloadable fonts) - Base technology for downloading assets at runtime] | * [https://bugzilla.mozilla.org/show_bug.cgi?id=1194338 Meta bug 1194338 (Support for downloadable fonts) - Base technology for downloading assets at runtime] | ||
** [https://bugzilla.mozilla.org/show_bug.cgi?id=1095719 Bug 1095719 - Download hyphenation dictionaries at runtime] | ** [https://bugzilla.mozilla.org/show_bug.cgi?id=1095719 Bug 1095719 - Download hyphenation dictionaries at runtime] | ||
| Line 59: | Line 60: | ||
| Currently Thunderbird uses mbox as primary storage format for mails (locally). The maildir format is also supported, but we have no converter for it yet. See [https://bugzilla.mozilla.org/show_bug.cgi?id=856087 bug 856087] | | Currently Thunderbird uses mbox as primary storage format for mails (locally). The maildir format is also supported, but we have no converter for it yet. See [https://bugzilla.mozilla.org/show_bug.cgi?id=856087 bug 856087] | ||
| JavaScript, maybe some C++ | | JavaScript, maybe some C++ | ||
| mkmelin | | [mailto:mkmelin+mozilla@iki.fi mkmelin] | ||
| mkmelin | | [mailto:mkmelin+mozilla@iki.fi mkmelin] | ||
| | | | ||
|- | |- | ||
| Line 76: | Line 77: | ||
! Comments | ! Comments | ||
|- | |- | ||
| Improve the JavaScript XMPP implementation | | Improve & expand the JavaScript XMPP implementation | ||
| | | The JavaScript XMPP implementation included in Instantbird/Thunderbird works well, but is lacking some features. This project should include a variety of small and larger improvements to the XMPP protocol. Feature-parity with libpurple's XMPP implementation is one of the prerequisites for replacing it with the JavaScript implementation and is an end-goal of this project. Examples of new/missing features include: | ||
* Support for DNS SRV | |||
* Room discovery (i.e. hook XMPP into the "awesometab") | |||
* Misc. bugs | |||
* Test coverage | |||
Students are expected to research a list of bugs and unimplemented features in the JavaScript XMPP code they intend to address. | |||
| JavaScript, XPCOM, an understanding of XMPP is desired | | JavaScript, XPCOM, an understanding of XMPP is desired | ||
| Florian Quèze | | Florian Quèze | ||
| aleth, | | aleth, [mailto:clokep@gmail.com clokep] | ||
| | | | ||
|- | |- | ||
| JavaScript Protocol Plug-in | | JavaScript Protocol Plug-in | ||
| | | Google Talk/Hangouts is one of the most popular networks to chat on now and is available over XMPP. Unfortunately, Google has slowly been breaking the interaction with their XMPP bridge such that features stop working. It is desirable to connect directly to Google Hangouts using their proprietary protocol. This would involve: | ||
* Adding a new Google Hangouts protocol | |||
* Improving and expanding shared code and APIs used by all JavaScript protocol plugins (IRC, XMPP, Yahoo and Twitter) | |||
* Improving documentation of the process for adding a protocol to Instantbird/Thunderbird | |||
* Reversing engineering of the network protocol | |||
* Add tests for the new protocol | |||
* Using the protocol on a day-to-day basis to dog-food the code | |||
Note that some implementations exist for other clients ([https://github.com/tdryer/hangups/ hangups in Python] and [https://bitbucket.org/EionRobb/purple-hangouts purple-hangouts in C]). | |||
| JavaScript, XPCOM, understanding of network protocols | | JavaScript, XPCOM, understanding of network protocols | ||
| Patrick Cloke | | Patrick Cloke [:clokep] | ||
| | | [mailto:clokep@gmail.com clokep], nhnt11 | ||
| | | Don't use Google Hangouts? Protocols we're interested in: Google Hangouts, Facebook, Bonjour, TextSecure/Signal, Telegram, or come talk to us! | ||
|- | |- | ||
| File transfer support | | File transfer support | ||
| Line 100: | Line 117: | ||
| XPCOM, JavaScript, XUL/HTML, WebRTC, networking protocols | | XPCOM, JavaScript, XUL/HTML, WebRTC, networking protocols | ||
| nhnt11 | | nhnt11 | ||
| | | [mailto:clokep@gmail.com clokep], nhnt11 | ||
| | | | ||
|} | |} | ||
| Line 170: | Line 187: | ||
| I'll happily add the backend to TaskCluster workers, so we can debug processes in CI tasks from a browser. | | I'll happily add the backend to TaskCluster workers, so we can debug processes in CI tasks from a browser. | ||
|- | |- | ||
| Make WebDriver/marionette match the featureset of Selenium FirefoxDriver. | | <strike>Make WebDriver/marionette match the featureset of Selenium FirefoxDriver.</strike> | ||
| WebDriver is a protocol for remote control of browsers that is in the process of being standardised at W3C. At this time, the most common WebDriver implementation used with Firefox is Selenium FirefoxDriver. However this has a number of problems e.g. incompatibility with e10s. For internal testing we have developed "marionette", a remote control API with the featureset to replace FirefoxDriver, but using a simple JSON-based protocol rather than HTTP used by WebDriver. To bridge these two worlds we have developed "wires", a proxy written in Rust that translates between W3C-standard WebDriver and the marionette protocol. This allows Firefox to be controlled by any WebDriver-compatible client. | | <strike>WebDriver is a protocol for remote control of browsers that is in the process of being standardised at W3C. At this time, the most common WebDriver implementation used with Firefox is Selenium FirefoxDriver. However this has a number of problems e.g. incompatibility with e10s. For internal testing we have developed "marionette", a remote control API with the featureset to replace FirefoxDriver, but using a simple JSON-based protocol rather than HTTP used by WebDriver. To bridge these two worlds we have developed "wires", a proxy written in Rust that translates between W3C-standard WebDriver and the marionette protocol. This allows Firefox to be controlled by any WebDriver-compatible client.</strike> | ||
Although "wires" currently implements most of the features of the W3C spec, there are a number of improvements required before it can match the functionality of FirefoxDriver. In particular it currently doesn't support the "actions" API which allows simulating low-level events (key presses, mouse clicks, touches, etc.), although this is well supported in marionette itself. There are also some non-standard features that are much requested by early adopters, including the ability to explicitly provide a Firefox profile to run. The purpose of this project would be to add those features to wires. | <strike>Although "wires" currently implements most of the features of the W3C spec, there are a number of improvements required before it can match the functionality of FirefoxDriver. In particular it currently doesn't support the "actions" API which allows simulating low-level events (key presses, mouse clicks, touches, etc.), although this is well supported in marionette itself. There are also some non-standard features that are much requested by early adopters, including the ability to explicitly provide a Firefox profile to run. The purpose of this project would be to add those features to wires.</strike> | ||
| Rust (basic level only) and other programming experience. | | <strike>Rust (basic level only) and other programming experience.</strike> | ||
| jgraham | | <strike>jgraham</strike> | ||
| jgraham | | <strike>jgraham</strike> | ||
| | | This project has been reprioritized and is no longer suitable for GSoC. | ||
|- | |- | ||
| Redesign SETA and give it TaskCluster support | | Redesign SETA and give it TaskCluster support | ||
| Line 183: | Line 200: | ||
| Python | | Python | ||
| [https://mozillians.org/en-US/u/armenzg/ armenzg] | | [https://mozillians.org/en-US/u/armenzg/ armenzg] | ||
| armenzg | | [https://mozillians.org/en-US/u/jmaher/ jmaher] armenzg | ||
| | | [https://docs.google.com/document/d/1rgZyUpHcIBuyo68Hr0fKuVd1w1j-Xdxae6LK4EXDnek/edit] | ||
|- | |||
| Give Treeherder the ability to schedule TaskCluster jobs | |||
| On Treeherder you can schedule Buildbot jobs which had not been scheduled before (see [[Try#Scheduling_jobs_with_Treeherder|Scheduling jobs with Treeherder]]). You can read more about the project in [https://docs.google.com/document/d/1TDF-UKYb16wxvAtqdzCFauTvJXSx_fjf7i1f8F3l7bk/edit# here]. | |||
| Python | |||
| [https://mozillians.org/en-US/u/armenzg/ armenzg] | |||
| armenzg [https://mozillians.org/en-US/u/jmaher/ jmaher] | |||
|} | |} | ||
| Line 198: | Line 221: | ||
! Comments | ! Comments | ||
|- | |- | ||
| | | [https://bugzilla.mozilla.org/show_bug.cgi?id=1223872 Reduce the frequency of update races in Balrog] | ||
| One of the key features of our update server's (Balrog) API is that it guards against update races - where multiple clients overwrite each others' changes to the same piece of data. In many cases clients are updating small, independent parts of the same larger piece of data, and the server should be able to safely merge the changes together rather than forcing clients to try again. This project will involve the design and implementation of an improved algorithm for safely accepting changes to Balrog's Release objects through the API. | | One of the key features of [https://wiki.mozilla.org/Balrog our update server's (Balrog)] API is that it guards against update races - where multiple clients overwrite each others' changes to the same piece of data. In many cases clients are updating small, independent parts of the same larger piece of data, and the server should be able to safely merge the changes together rather than forcing clients to try again. This project will involve the design and implementation of an improved algorithm for safely accepting changes to Balrog's Release objects through the API. | ||
| Python | | Python | ||
| [https://mozillians.org/en-US/u/bhearsum/ bhearsum] | | [https://mozillians.org/en-US/u/bhearsum/ bhearsum] | ||
| Line 224: | Line 247: | ||
| [https://github.com/servo/servo/wiki/Summer-of-Code-2016:-File-support In-depth project details] | | [https://github.com/servo/servo/wiki/Summer-of-Code-2016:-File-support In-depth project details] | ||
|- | |- | ||
|} | |} | ||
| Line 250: | Line 266: | ||
| [https://mozillians.org/en-US/u/jvehent/ Julien Vehent :ulfr] & [https://mozillians.org/en-US/u/kang/ Guillaume Destuynder :kang] | | [https://mozillians.org/en-US/u/jvehent/ Julien Vehent :ulfr] & [https://mozillians.org/en-US/u/kang/ Guillaume Destuynder :kang] | ||
| MIG (github.com/mozilla/mig) is a distributed digital forensics framework deployed across thousands of systems at Mozilla. It is used by various groups to maintain good security levels across the environments, and investigate incidents and vulnerabilities. | | MIG (github.com/mozilla/mig) is a distributed digital forensics framework deployed across thousands of systems at Mozilla. It is used by various groups to maintain good security levels across the environments, and investigate incidents and vulnerabilities. | ||
|} | |||
==NSS (Network Security Services)== | |||
{| class="standard-table" border="1" style="border-collapse: collapse" | |||
|- | |||
! Title | |||
! Details | |||
! Skills Needed | |||
! Reporter | |||
! Mentor(s) | |||
! Comments | |||
|- | |||
| Implement RFC7512 PKCS#11 URI support and system integration | |||
| [https://tools.ietf.org/html/rfc7512 RFC7512] defines a URI standard for identifying PKCs#11 tokens and the objects therein. We need to implement a PK11_FindCertByURI() or similar function, and also make it possible to obtain/generate the URI for a given CERT and other objects which have been found/selected by other means. See [https://bugzilla.mozilla.org/show_bug.cgi?id=1162897 bug 1162897] for details. Also, NSS does not obey the system configuration for which PKCS#11 tokens to load, as described in [https://bugzilla.mozilla.org/show_bug.cgi?id=248722 bug 248722]. We should fix this too. | |||
See dev-tech-crypto email at https://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg12493.html | |||
| C coding, familiarity with PKCS#11 preferable | |||
| dwmw2 | |||
| [mailto:rrelyea@redhat.com Bob Relyea], [mailto:david.woodhouse@intel.com David Woodhouse (dwmw2)] | |||
|} | |} | ||