Synchronizing Github Issues with W3C Mailing Lists
Manu Sporny edited this page Nov 18, 2015
·
4 revisions
Pages 89
- Home
- A Payments Initiation Architecture for the Web
- Adoption2017
- Agenda 12th November 2015 at 1700 UTC
- Agenda 17th December 2015 at 1700 UTC
- Agenda 19th November 2015 at 1700 UTC
- Agenda 20160107
- Agenda 20160121
- Agenda 20160128
- Agenda 20160204
- Agenda 20160211
- Agenda 20160310
- Agenda 20160317
- Agenda 20160331
- Agenda 20160407
- Agenda 20160414
- Agenda 20160421
- Agenda 20160428
- Agenda 20160505
- Agenda 20160512
- Agenda 20160519
- Agenda 20160526
- Agenda 20160602
- Agenda 20160609
- Agenda 20160616
- Agenda 20160623
- Agenda 20160728
- Agenda 20160804
- Agenda 20160811
- Agenda 20160818
- Agenda 20160825
- Agenda 20160901
- Agenda 20160908
- Agenda 20160915
- Agenda 20161006
- Agenda 20161020
- Agenda 20161027
- Agenda 20161103
- Agenda 20161110
- Agenda 20161117
- Agenda 20161201
- Agenda 20161208
- Agenda 20161215
- Agenda 20170105
- Agenda 20170112
- Agenda 20170119
- Agenda 20170126
- Agenda 20170202
- Agenda 20170209
- Agenda 20170216
- Agenda 20170223
- Agenda 20170302
- Agenda 3rd December 2015 at 1700 UTC
- Agenda for 3rd March telco
- All in the Browser
- Browser with remote Payment Apps
- Call for Consensus FPWD
- CFC_20140412
- Checkout API
- Components
- DeploymentExamples
- Extensibility_Notes
- F2F Agenda
- FTF March2017
- FTF Sep2016
- How it Works
- How the Working Group works
- Issue Summary
- MagWebinar
- Meeting Proposal 20161128
- Meetings
- Mobile Platform
- Networks List
- PaymentApp_Notes
- PaymentRequestFAQ
- PMI_Notes
- Proposed F2F Day 2 agenda
- RegistrationTypes
- Security and Privacy Considerations
- Spec_Notes
- Support for multi price and currency
- Synchronizing Github Issues with W3C Mailing Lists
- TestSuite
- TPAC 2015 issues list
- Web Payment Deployment Examples
- Web Payments Working Group FTF Meeting (July 2016)
- Web Payments Working Group Plan
- WPWG FTF Feb 2016
- WPWG FTF Feb 2016 Requirements
- Show 74 more pages…
Mailing list archives
Issues
- General
- Payment Request API
- Payment Method Identifiers
- Basic Card Payment
- Payment Apps API
- HTTP API and Messages
Tests
Adoption
Previous Topics
Clone this wiki locally
Introduction
The W3C has traditionally done most of its work through mailing lists and the W3C issue tracker. New groups at W3C are migrating to Github and need a mechanism that supports the W3C standardization process. This wiki page documents a way to enable a group at W3C to use Github for all of their version control and issue tracking needs.
Note: There is a mechanism that requires groups to contact Dom to setup issue mirroring, but the current solution doesn't enable people to respond to issues via a mailing list.
Goals
- Enable multiple Github repositories to be used for version control on specifications.
- Enable issues to be raised on specifications through Github.
- Enable issues to be responded to via Github's website.
- Enable issues to be responded to via W3C mailing lists (no Github account required).
- Reduce the attack surface on the mailing lists and Github.
Setting Up Github Issue Syncing
Requirements
- A W3C staff contact that is able to manage the mailing list for the W3C group you are trying to setup on Github.
- An hour to do the setup and test the configuration.
- A smartphone (for two-factor authentication).
Setup
-
Create a new user account on Github.
- Ensure that the email address you use to register is the public mailing list address for the W3C group. For example: [email protected].
- After registration, check the W3C mailing list "Admin action" queue. Use the verification link in the admin queue to verify the email address. Delete the email from the admin queue (do not let it through).
- Setup two-factor authentication for the account.
- Download and install Google Authenticator on your smartphone.
- Setup two factor authentication
- Make sure your "delivery mode" is set to "authenticator application".
- Make sure you save your recovery codes.
- Save the username and password, recovery codes, and two-factor shared secret key (save the QRCode image, or the manual code setup). Share this information with other W3C staff and chairs for the group.
- Watch Github repositories that the group should be notified of when issues are raised or discussed.
How it works
- Any issue that is created will trigger an email to be sent to the public mailing list of the W3C group.
- Any response to an issue will trigger an email to be sent to the public mailing list.
- Responding to an issue via email will log the response to the Github issue and send an email to the public mailing list.
Security Concerns
- It is possible to spam the list by:
- Creating a throw-away Github user account and responding to issues in the Github issue tracker. This is the easiest attack. The driver for this attack is to annoy people on the mailing list and to cause a disruption. The response to the attack is to delete the comment and notify Github that an account is being abused.
- Figuring out the reply addresses from the email source (by subscribing to the mailing list), and then responding anonymously via email to the issue. This attack will send an email to the mailing list, but the spam can be deleted via Github's issue tracker. The driver for this attack is to annoy people on the mailing list and to cause a disruption. The response to the attack is to delete the comment. A complete response to this sort of attack requires a bot to be written (Dom has one in the works) that would authorize posts based on both originating email address and/or Github user account that made the post (this would be hard/heavyweight to manage).
- Password reset codes can be sent to the mailing list. However, as long as two-factor authentication is turned on, it will be impossible for anyone to send a reset code to the mailing list using Github's "I forgot my password" feature. The reset code will still be sent to the mailing list, but an attacker would need the two-factor shared secret to change the login password.