Clarify security best practises
- @johannesweiss: Needs clarification because the current language is ambiguous and it's not clear what to do when
- @varland: Can be lightweight but need to be clear, thinks we should be prescriptive. Right balance is important but if in doubt specify exactly what to do when. When people wonder what the right step is, mistakes happen.
- Should we get some advice on the best practises?
- What's the best notification mechanism?
- email? who controls the email?
- con: no guaranteed delivery
- con: who owns the mailbox
- email address that automatically creates a post in a private area (accessible only to SSWG)
- seems like a good option
- email? who controls the email?
- [ACTION] @tomerd to ask Mishal if we can have an email address that goes to the private forums area?
- [ACTION] @varland to see if there's expertise at Amazon that could give advise in one of the next SSWG meetings
Misc
- "SEO" for SSWG package index: We should add a very short description what each package does (so search engines and humans know)
- [ACTION] @0xTim/@kmahar to send the description of the Vapor packages & others he knows well to Johannes
- [ACTION] @johannesweiss to make the PR to the website with the short updates
- Non-Foundation UUID?
- Fabian Fett has a third-party package, that has been vendored in a bunch of places
- Vapor have had similar situations (eg. JSON parsing) but their general opinion is to fix issues in Foundation over creating new packages
- The team is generally very interested in improving Foundation's suitability for server (eg. JSON, UUID, Date)
- @tachyonics: Maybe a package of "identifiers" eg. Snowflake ID, UUID, ID generators could be interesting as just UUID in a package feels small
- @kmahar MongoDB also has "Object ID" in that space
MultipartKit pitch
- Is it a good idea to pitch? Yes
- Vapor have split out their implementation, only depends on NIO, so could be used anywhere.
-
@tachyonics: Which github org should it leave
vapor/swift-server? - [ACTION] Tim to pitch MultiPartKit
Guidance around log levels in libraries
-
@0xTim: Vapor has libraries that log above
debug. And recently there was discussion if that's a good idea -
@0xTim's personal opinion:
debug/tracefine,errorwhen something actually went wrong in the library. Other log levels should be avoided for libraries - @johannesweiss: library authors don't know what users use the libraries for. So certain errors may be expected (eg. a "connection error") and therefore libraries shouldn't log possibly expected failures too high (especially if the failure is communicated via API already).
- @ktoso: good rule of thumb: If users cause a failure, then don't log. If it's some internal runtime thing that would otherwise be very hard to debug for users: log
- @tachyonics: Amazon scan for errors/warning, so libraries need to be careful not to log too much at these levels. We should create some guidance around it.
- [ACTION] @ktoso to create a document to come up with guidance
Year 2020 SSWG summary
- has been outstanding for quite some time, should do this soon
- [ACTION] @tomerd to find the summary posts from the old notes
- [ACTION] @johannesweiss to start a first draft from there
AsyncSequences
- clarifications about sync cancel, vs. async cancel, vs. just deinit
5.4 regressions around property wrappers (and similar)
- Vapor are experiences in 5.4 compiler regressions around property wrappers
- file in bugs.jira.org, if necessary discussion in forums
