Community:SummerOfCode16:Brainstorming: Difference between revisions

(→‎Automation & Tools: - new project)
 
(6 intermediate revisions by 5 users not shown)
Line 63: Line 63:
| Javascript
| Javascript
| marco
| marco
|
|
|  
|-
| RFC7512 URI support (PKCS #11 URI)
| [https://bugzilla.mozilla.org/show_bug.cgi?id=1162897 bug 1162897]
and
[https://bugzilla.mozilla.org/show_bug.cgi?id=248722 bug 248722]
| C
|
| rrelyea and dwmw2
| Already entered [[Community:SummerOfCode16]]
|-
|-
|}
|}
Line 223: Line 231:
! Mentor(s)  
! Mentor(s)  
! Comments
! Comments
|}
==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.
| C coding, familiarity with PKCS#11 preferable
| dwmw2
| rrelyea,dwmw2
|}
|}


Line 299: Line 280:
! Mentor(s)  
! Mentor(s)  
! Comments
! Comments
|-
! Debugging failures seen in CI Infrastructure
! there are many things we can do to make the developer experience better when investigating a test job.  From retriggering a job to collecting verbose logging or profiling data, to using a 1 click loaner to not only reproduce but to debug and fix issues, there are many parts of the CI system that we can make small improvements upon to simplify and make dealing with test jobs in CI more enjoyable.  Full details available [https://docs.google.com/document/d/1kiTt79hnqP65UDYobm0ekYV27-0nRE9IDo9AB8NkSLQ/edit here]
! python, javascript
! Joel Maher
! Joel Maher
!
|-
|-
|}
|}
Line 441: Line 429:
! Mentor(s)  
! Mentor(s)  
! Comments
! Comments
|-
| SemVer policy checker
| Rust's library ecosystem works with "semantic versioning" (semver), which allows the version numbers of libraries to signify backwards-compatibility constraints. Roughly speaking, if your code works with version `X.Y` of some library, it should work with `X.(Y+1)` -- a new "minor release" -- as well.
In practice, actually ensuring compatibility is quite subtle, and in Rust, there are some library changes that could theoretically break client code, but which we want to allow anyway. Our full stance on semantic versioning is written up in an RFC: https://github.com/rust-lang/rfcs/pull/1105
The goal of this project is to build a tool that can tell whether a set of changes to a library is valid under Rust's semver rules. Building this tool will likely require some hacking on the compiler itself (to produce the necessary information), and will hopefully result in some reusable infrastructure that can be applied to other projects as well.
| Familiarity with Rust
| Aaron Turon
| Brian Anderson, Aaron Turon
|
|-
|-
|}
|}
Confirmed users
3,376

edits