diff options
| -rw-r--r-- | archive/2021-09-28-announcement-inspiration | 117 | ||||
| -rw-r--r-- | archive/2021-09-28-design-comments | 23 |
2 files changed, 140 insertions, 0 deletions
diff --git a/archive/2021-09-28-announcement-inspiration b/archive/2021-09-28-announcement-inspiration new file mode 100644 index 0000000..0ab27ab --- /dev/null +++ b/archive/2021-09-28-announcement-inspiration @@ -0,0 +1,117 @@ +Summary + * Announce via mailing list + * It happens in our community + * It makes it easy to respond + * It makes it easy to forward + * We can keep our website minimal for now (landing page) + * Announcements seem to be relatively short + * Max 500 words is probably a good rule of thumb + * Shorter if you have a few polished links to reference + * Possible points to make, also based on what we discussed before + * What type of project are we + * What is the project about + * What is the purpose of project announcement + * What is the timeline leading up to announcement + * What is the current project status + * What are the next steps + * Who is involved, people and funders + * Relevant links to help the reader navigate sigsum + * (Get feedback from a communicator) + +Other things to keep in mind + * Double check that what we are linking is in good enough shape + * E.g., small TODOs in sigsum-log-go README.md (fix links) + * We should think about what questions people might have in response to announcement + * Perhaps it would be a good idea to give design.md FAQ some love + * Try to avoid too much detail, we can make sigsum blog posts at a later stage + * The fact that we are aware of sigstore should probably be clear + * Let people ask, that's fine + +--- +Warning: I have not spent much time verifying if there were other announcements +than the ones specified below. It is the result of a v. quick search / analysis. + +(Some of the below links are not even project announcements, but rather +announcement of 'we are developing or developed cool thing XXX'. I kept +everything I found useful as inspiration in case it helps anyone else.) + +Debian + * https://www.debian.org/doc/manuals/project-history/project-history.en.pdf + * See ยง1.1 + * How: mail + * Points + * This is a work in progress + * It is cool because XXX + * Purpose of anouncement is XXX + * It is better than XXX because A,B,... + +Tails (back then amnesia) + * https://lists.torproject.org/pipermail/tor-talk/2009-August/002667.html + * How: mail + * Points + * This work is about XXX + * Licence is XXX + * Purpose of announcement is XXX + * We prefer if you get in touch via XXX + +Qubes + * https://blog.invisiblethings.org/2010/04/07/introducing-qubes-os.html + * How: post on website + * Points + * Timeline before announcing project + * Project is about doing XXX + * Current project status is XXX + * Learn more via resources XXX + +Signal + * https://signal.org/blog/signal/ + * How: post on website + * Points + * Timeline leading up to announcement + * Mision and work is about XXX + * Next steps + * Who is involved + * "Give it a try!" + +Wireguard + * https://lists.zx2c4.com/pipermail/wireguard/2016-June/000002.html + * How: Mail + * Points + * Been at this for a while, confident enough to launch now + * Purpose of launch is XXX + * Link relevant resources (paper, website, git, mailing list) + * One paragraph primer (118 words) + +Firecracker + * https://aws.amazon.com/about-aws/whats-new/2018/11/firecracker-lightweight-virtualization-for-serverless-computing/ + * How: post on website + * Points + * We are launching product XXX + * Key concepts are XXX + * How it is used / can be used + * Visit XXX to learn more + +System Transparency + * https://mullvad.net/en/blog/2019/6/3/system-transparency-future/ + * How: post on website + * Points + * Key questions and background that motivated this work + * We believe that ST gives you the ability to XXX + * Call to action + * Little detail, link to ST white paper + +Sigstore + * How: press releases on partner websites + * https://security.googleblog.com/2021/03/introducing-sigstore-easy-code-signing.html + * Points + * What is the problem + * Announcement project with goal/mission XXX + * Problem space is related to XXX, involved tehniques are... + * Collaboration is between XXX + * Request for feedback + * Next steps + * https://www.linuxfoundation.org/en/press-release/linux-foundation-announces-free-sigstore-signing-service-to-confirm-origin-and-authenticity-of-software/ + * Points + * Collaborators XXX want to achive XXX + * Quotes from involved people that explain idea and purpose + * Refer to website for more information diff --git a/archive/2021-09-28-design-comments b/archive/2021-09-28-design-comments new file mode 100644 index 0000000..42cebec --- /dev/null +++ b/archive/2021-09-28-design-comments @@ -0,0 +1,23 @@ +-design.md file: [rohonk] + + Line 39-49: This part is very important as it clearly states the goal of the project. Also it draws a comparison between our goal and what we want to achieve different/better than the previously available certificate transperancy. I would like to suggest if we can make a different subsection 1.2, which deals with the comparative study. + + Line 60-62: Using Claimant Model. + + Line 88-89: Does it mean that the fingerprint i.e. (hash of the opaque data is already stored in the sigsum log)? And now the Claimant checks with the log. + + Figure 1: What happens if one of the participating party (Believer/Claimant) act maliciously by deviating from the protocol? + + Line 109-113: Introduction to DNS in order to avoid log poisoning is a very interesting concept. + + Line 141-158: Each of the different attack circumstances needs to be dealt with in the security proof. Here we are considering an external attacker as a threat. Is it a good question to ask that what happens when the trusted party act maliciously within the system? + + Line 183-185: This part partially address my concern stated in the previous point. + + Steps for Security Proof: + https://git.sigsum.org/sigsum/tree/archive/2021-06-21-system-overview-ascii + 1. Writing pseudocodes for each interaction i.e. Claimant <> Believer , + Claimant <> Witness. + 2. Have a threat model considering all possible misbehaviours. + 3. Cryptographic Schemes already determined (CRH, ECDSA) + 4. Decide on what kind of security proof is necessary like pen and paper proof or using software like Proverif/Tamarind? |